2011-02-11 74 views
5

让我首先对整个主题的长度表示歉意。这将是相当长的,但我希望确保信息清晰无误地完成。使用NHibernate和公司业务逻辑的OData WCF数据服务

在这里,我们有一个现有的ASP.NET WebApplication。用.NET Framework 3.5 SP1上的C#ASP.NET编写。前段时间,使用WCF和SOAP为此Web应用程序开发了一个初始API,以允许外部各方与应用程序进行通信而无需依赖浏览器。

该API存活了一段时间,但最终请求创建了一个新的API,它是RESTfull并依赖于新技术。我被赋予了这个任务,并且使用Microsoft MVC 2框架创建了最初的API,它运行在我们的ASP.NET WebApplication中。为了让它正常运行,这段时间最初很安静,但目前我们能够对应用程序进行REST调用,以接收详细描述我们资源的XML。

我参加过一个微软网络营销活动,我立刻被OData概念出售。它与我们正在做的非常相似,但这是一个由更多玩家支持的协议,而不是我们自己的实施。目前,我正在开发PoC(概念验证)以重新创建使用OData协议和WCF DataService技术开发的API。

在搜索互联网获取NHibernate 2以使用Data Services后,我成功创建了API的ReadOnly版本,该版本允许我们通过将传入的查询请求映射到我们的内部来从内部业务层读出实体业务层。 但是,我们希望有一个功能性API,允许使用OData协议创建实体。所以现在我有点卡住如何继续。我一直在阅读以下文章:http://weblogs.asp.net/cibrax/default.aspx?PageIndex=3

以上明确地很好地解释了如何将自定义DataService映射到NHibernate层。我已经用它作为继续的基础,但我有一个“问题”,我不想使用NHibernate将我的请求直接映射到数据库,但是我希望将它们映射到我们的业务层(一个独立的DLL ),它根据访问权限,权限和触发器执行大量检查,约束和更新。

所以我想问的是,例如我创建了自己的NhibernateContext类,如上所述,但是依赖于我们的业务层而不是NHibernate会话,它可以工作吗?我可能不得不依赖反射来找出我在运行时使用的对象的类型,并调用正确的业务类来执行更新和删除。所以

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

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

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

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

,将这项工作,或将性能使它无用:

要与SMaL公司ASCII图片展示? 或者我只是在这里错过了球? 这个想法是我希望重新使用来自OData WCF DataService的BUL & DAL层中存储的任何逻辑。

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

我希望这有点清楚我想解释什么,我希望有人能帮助我解决这个问题。

+0

纠正上面的链接非常有用的文章(包括来源等)http://weblogs.asp.net/cibrax/archive/2010/08/13/nhibernating-a-wcf-data-service.aspx – paulecoyote 2011-08-04 15:42:41

回答

1

魔鬼是在细节,但它听起来像你提出的设计应该工作。

DataService类是您可以定义适用于每个人的访问权限,配置设置和自定义操作的位置。在这种情况下,我认为你应该更多地关注数据上下文(DataService中的'T')。

对于上下文,实际上有两条相互交织的路径:读取和写入。通过IQueryable入口点进行读取。编写一个LINQ提供程序是一个很好的工作,但NHibernate已经支持这个,尽管它会返回我认为我们称之为DAL实体的东西。如果您可以用数据库能够理解的方式表达这些信息,则可以使用查询拦截器进行访问检查。

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

有两个地方可能会从一种物体跳到另一种物体。一个是在GetResource()API中,你可以从中获得一个IQueryable,可能是DAL实体。另一个是在ResolveResource()中,运行时需要一个对象序列化,就像它从IQueryable获得的一样,所以它可能也是一个DAL实体。

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

+0

是啊那是我想要遵循的道路。然而,这给我带来了另一个问题。在我发布的链接中,接口与类“对象”一起使用它的方法。我是通过使用反射还是通过解析URL来派生正确的对象,然后将对象转换为正确的实体模型?或者我应该为每个实体制定一个特定的DataService实现并重载onRequest方法来创建正确的实例? 然后再考虑一个通用实现,然后根据类的类型调用正确的业务逻辑。 – 2011-02-14 08:10:54