具有 NHibernate 和企业业务逻辑的 OData WCF 数据服务

Question

首先让我为整个主题的长度表示歉意。这将相当长，但我希望确保该消息清晰无误。

在公司，我们有一个现有的 ASP.NET Web 应用程序。在 .NET Framework 3.5 SP1 上用 C# ASP.NET 编写。不久前，使用 WCF 和 SOAP 为此 Web 应用程序开发了一个初始 API，以允许外部各方在不依赖浏览器的情况下与应用程序进行通信。

这个 API 存在了一段时间，但最终要求创建一个新的 RESTfull API，并依赖于新技术。我接受了这项任务，并使用 Microsoft MVC 2 框架创建了初始 API，在我们的 ASP.NET Web 应用程序中运行。最初需要一些时间才能使其正常运行，但目前我们可以对应用程序进行 REST 调用以接收详细说明我们的资源的 XML。

我参加过 Microsoft WebCamp，我立即就被 OData 概念所吸引。这与我们正在做的非常相似，但这是一个由更多玩家支持的协议，而不是我们自己的实现。目前，我正在研究 PoC（概念验证），以重新创建我使用 OData 协议和 WCF DataService 技术开发的 API。

在互联网上搜索 NHibernate 2 与数据服务配合使用后，我成功创建了 API 的只读版本，该 API 允许我们通过将传入查询请求映射到业务层来从内部业务层读取实体。 然而，我们希望有一个功能性 API，它还允许使用 OData 协议创建实体。所以现在我有点困惑如何继续。我一直在阅读以下文章： http://weblogs.asp.net/ cibrax/default.aspx?PageIndex=3

上面的文章很好地解释了如何将自定义 DataService 映射到 NHibernate 层。我以此为基础继续，但我有一个“问题”，我不想使用 NHibernate 将我的请求直接映射到数据库，但我希望将它们映射到我们的业务层（一个单独的 DLL） ）根据访问权限、特权和触发器执行大量检查、约束和更新。

所以我想问的是，例如，我创建了自己的 NhibernateContext 类，如上面的文章所示，但依赖于我们的业务层而不是 NHibernate 会话，它可以工作吗？我可能必须大量依赖反射来确定我在运行时使用的对象的类型，并调用正确的业务类来执行更新和删除。

用一张小的 ascii 图片来演示：

                              *-----------------*
                              *   Database      *
                              *-----------------*

                              *------------------------*
                              * DAL(Data Access Layer) *
                              *------------------------*

                              *------------------------*
                              * BUL (Bussiness Layer)  *
                              *------------------------*
                              *---------------*  *-------------------*
                              * My OData stuff*  * Internal API      *
                              *---------------*  *-------------------*

                                                 *------------------*
                                                 * Web Application  *
                                                 *------------------*

那么，这会起作用吗？或者性能会使其变得无用吗？ 或者我只是在这里错过了球？ 我的想法是，我希望重用存储在 BUL 和 BUL 中的任何逻辑。 DAL 层来自 OData WCF DataService。

我正在考虑创建从 Data.Services 命名空间中的 EntityModel 类继承的新类，并创建一个新的 DataService 对象来标记对 BUL 和 BUL 的所有调用。达尔和API 层。然而，我不确定在哪里/谁拦截创建和删除资源的请求。

我希望我想解释的内容很清楚，我希望有人能在这方面帮助我。

Answer 1

细节决定成败，但听起来你提出的设计应该可行。

您可以在 DataService 类中定义适用于每个人的访问权限、配置设置和自定义操作。在这种情况下，我认为您将更多地关注数据上下文（DataService 中的“T”）。

对于上下文，确实有两个有趣的路径：读取和写入。读取通过 IQueryable 入口点进行。编写 LINQ 提供程序是一项艰巨的工作，但 NHibernate 已经支持这一点，尽管它会返回我想象中的 DAL 实体。如果您可以用数据库可以理解的术语表达这些内容，则可以在此处使用查询拦截器进行访问检查。

更新路径来自我所理解的您试图运行更多业务逻辑的地方（您提到了验证、额外更新等）。为此，您需要关注 IUpdatable 实现（如果您使用的是最新版本，则为 IDataServiceUpdateProvider）。在这里您可以使用任何您想要的对象 - 它们可以是 DAL 对象或业务对象。您可以在 DAL 中执行所有操作，然后在 SaveChanges() 上运行验证，或者在业务对象上执行所有操作（如果它们在运行时进行验证）。

您可以在两个地方从一种对象“跳”到另一种对象。一种是在 GetResource() API 中，您可以在其中获取 IQueryable，大概是 DAL 实体的形式。另一个是在 ResolveResource() 中，运行时要求一个对象进行序列化，就像从 IQueryable 中获取一样，因此它可能也是一个 DAL 实体。

希望这会有所帮助 - 对非统一 API 进行统一访问可能很困难，但通常非常值得！