Question

为了关注这里的问题，我们可以说我有一个数据库层和一个应用层。因此，对于应用程序来访问数据库，我必须通过数据库层（当然）。

现在问题是我想用LINQ编写查询。我可以在这里走两条不同的道路。一种方法 [A] 将在DBLayer中创建大约300个单独的函数，并从应用程序中调用它们（例如GetAllUsers()）。

OR [B] DBLayer可能或多或少只提供一个DBContext，然后我可以从应用层（DBContext.GetAll<Users>().Where(x => x...）运行LINQ查询。

我认为[B]路径会更有吸引力，或者至少不那么烦人，因为它不会充满小功能。但是你会说什么呢？

然而[B]路径的问题是，如果我可以避免它，我不想在Application中引用NHibernate，但我似乎无法访问LINQ for NHibernate函数没有引用它。对此有一个很好的解决方案吗？

Answer 1

选项A提及您不需要创建300个功能，您需要根据应用需求创建尽可能多的功能。并且一些函数可以获得一个减少函数nubmer的Criteria。

最重要的是，所有这些函数都将返回app对象而不是持久性对象，从而保持应用程序的其余部分与持久性分离。当然，业务/ ui对象也不应该知道NH。

Answer 2

使用LINQ（B）的解决方案当然更可取（与解决方案A中描述的300个单独函数相比）

实际上非常容易。您的数据层将只发布今天的标准： IQueryable 。

本机NHibernate LINQ提供程序将为您做到这一点：

var query = session.Query<TEntity>()

实际上是返回 IQueryable<TEntity> 的 var查询

所以数据层包含（接口IDao ...）可能就像这个（下面是实现）

public virtual IQueryable<MyEntity> GetQueryable()
{
    var session = ....
    return sesion.query<MyEntity>();
}

在这种情况下，没有上层会注意到它正在使用NHibernate。实际上在某些情况下可以收到不同IQueryable提供商的结果

EXTEND：

我还想将一个（我甚至会说有争议的）链接附加到Ayende阻止帖子：The DAL should go all the way to UI

引用：

......我目前的方法完全不同。我定义了查询，其中包含查询的实际业务逻辑，但我将该查询向前传递到我的应用程序的更高级别。可以对查询（投影，分页，排序等）进行任何其他处理。这样，我的查询将被关闭以进行修改并打开扩展，因为它们可以被更高级别的代码进一步操纵...

虽然Ayende一般不是（至少在撰写本文时：Don’t castrate your architecture是数据，业务，服务层的粉丝......上面的logcic类似：

将查询（IQueryable）传递给上层。如果需要，应用一些自定义过滤器（更多地限制结果），但让客户端应用程序（用户）使用它来查询您的API