我对 NHibernate 相当陌生，我见过的大多数示例都在基础上添加了一些抽象层Criterion or DetachedCriterion类。在简单的情况下，它是某种Query类可能看起来像这样：
public class Query<T>
{
public List<QueryCondition> Conditions { get; set;}
}
public class QueryCondition
{
public string Property { get; set; }
public ComparisonEnum Comparison { get; set; }
public object Value { get; set; }
}
在服务或存储层的某个位置，查询抽象被转换为适当的CriterionNHibernate 随后使用该对象来检索记录。
当然，这个例子过于简单化了。在我的项目中，我走上了创建一个Query<T>包含的类AND and OR条件，并且接口定义了一个方法来转换我的自定义条件（在某些情况下比简单的条件要复杂得多）QueryCondition上面的例子）到AbstractCriterion添加到DetachedCriterion内置于服务中。我这样做的部分原因是我保留关联的查询，以便用户可以定义一个列表并保存它，但最大的原因是它似乎是我见过的 n 层 NHibernate 项目的流行方法。
然而，我开始怀疑这种抽象的开销是否值得。它并没有让我摆脱对 NHibernate 的依赖。因为我使用 futures 来批量查询，所以我的项目都必须引用 NHibernate 才能至少访问IFutureValue创纪录的计数。除此之外，我的Query<T>类与 NHibernate 有着千丝万缕的联系，因为它构建了AbstractCriterion（尽管我可以轻松地将其拉到一个单独的类中）。
无论如何，我看得越多，我就可以简单地更换我的Query<T> with a DetachedCriteria。两者都是可序列化的，因此我可以保留它们，并且由于我不会独立于标准本身构建标准条件，因此我认为我不太可能遇到复杂查询的别名问题。就抽象而言，这个抽象似乎并没有提供太多与复杂性的隔离。
谁能告诉我为什么我应该抽象 NHibernate 标准的理由以外“有一天你可能会改变你的 ORM”（我很乐意说在项目的这个阶段这是不可能的）？
它在单元测试方面具有优势。CriteriaAPI 在构建查询方面确实非常出色，但对于模拟来说确实很痛苦。如果您有这样的课程，您可以轻松验证条件：
query.Conditions.Contains(requiredCondition);
在 Criteria 中，您需要一些模拟并验证应用程序的行为，而不是输出，这要困难得多。
只是因为这个原因我还在使用Repository我的应用程序中的模式，而不仅仅是使用ISession直接地
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
