使用NHibernate和公司業務邏輯的OData WCF數據服務

讓我首先對整個主題的長度表示歉意。這將是相當長的，但我希望確保信息清晰無誤地完成。使用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的所有調用。然而，我不確定在哪裏/誰攔截創建和刪除資源的請求。

我希望這有點清楚我想解釋什麼，我希望有人能幫助我解決這個問題。

來源

2011-02-11 coding-bunny

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

魔鬼是在細節，但它聽起來像你提出的設計應該工作。

DataService類是您可以定義適用於每個人的訪問權限，配置設置和自定義操作的位置。在這種情況下，我認爲你應該更多地關注數據上下文（DataService中的'T'）。

對於上下文，實際上有兩條相互交織的路徑：讀取和寫入。通過IQueryable入口點進行讀取。編寫一個LINQ提供程序是一個很好的工作，但NHibernate已經支持這個，儘管它會返回我認爲我們稱之爲DAL實體的東西。如果您可以用數據庫能夠理解的方式表達這些信息，則可以使用查詢攔截器進行訪問檢查。

更新路徑是從我所瞭解的您試圖運行更多業務邏輯的位置（您提到的驗證，額外更新等）。爲此，您需要關注IUpdatable實現（如果您使用的是最新版本，則需要IDataServiceUpdateProvider）。在這裏，您可以使用任何您想要的對象 - 它們可以是DAL對象或業務對象。您可以在DAL中執行所有操作，然後在SaveChanges（）上運行驗證，或者在業務對象進行驗證時執行所有操作。

有兩個地方可能會從一種物體跳到另一種物體。一個是在GetResource（）API中，你可以從中獲得一個IQueryable，可能是DAL實體。另一個是在ResolveResource（）中，運行時需要一個對象序列化，就像它從IQueryable獲得的一樣，所以它可能也是一個DAL實體。

希望這會有所幫助 - 對非統一API進行統一訪問可能很困難，但往往非常值得！

來源

2011-02-11 19:58:35

是啊那是我想要遵循的道路。然而，這給我帶來了另一個問題。在我發佈的鏈接中，接口與類「對象」一起使用它的方法。我是通過使用反射還是通過解析URL來派生正確的對象，然後將對象轉換爲正確的實體模型？或者我應該爲每個實體制定一個特定的DataService實現並重載onRequest方法來創建正確的實例？然後再考慮一個通用實現，然後根據類的類型調用正確的業務邏輯。 – 2011-02-14 08:10:54

使用NHibernate和公司業務邏輯的OData WCF數據服務

回答

相關問題