推薦使用SOA（Microsoft CRM）從2層NHibernate遷移到3層的方法是什麼？

給定一個（當前）項目，它實現了一個具有良好分離的層級業務層的2層體系結構，遵循典型的generic DAO architecture as pioneered by Bill McCafferty on CodeProject，並且在NHibernate in Action的第10章中進行了簡要解釋。推薦使用SOA（Microsoft CRM）從2層NHibernate遷移到3層的方法是什麼？

此項目必須通過Microsoft CRM作爲使用Web服務的中間層來執行CRUD操作和業務邏輯。客戶關係管理中定義了自定義對象和方法，以模擬當前情況。

我不認爲這是一個好主意，開始移動POCO來回像我們以前一樣。此外，延遲加載，緩存和併發等功能都必須區別對待。考慮到我們必須儘量減少中間層和演示層之間的呼叫帶來另一個挑戰。

實施DTO似乎是正確的行動動因，但需要一條漫長的道路（加上團隊的學習路徑）。我之前完成了SOA項目，但現在我正在尋找阻力最小的路徑。我們可以繼續使用NHibernate，即使直接數據庫連接不會成爲選項嗎？我們是否必須重新思考.NET 4.0中引入的設計，或者是斷開連接的實體，或許是一種選擇？它會變得多麼痛苦？

來源

2010-06-28 Abel

你怎麼能使用NHibernate的時候DB無法直接訪問是可能的嗎？ – 2010-07-01 14:08:48

@afsharm，好吧，這是這裏的問題。 NH與連接器一起工作，並且在技術上，您應該能夠將HSQL的翻譯器插入到FetchXML中。考慮到XRM（如Josh所提到的）是使用ADO.NET的圖層，可能會將兩者結合起來。另一個問題是否也是可行的。 – Abel 2010-07-08 11:16:07

我們使用XRMLinq - http://www.xrmlinq.com。它構建你的DTO對象，然後你可以使用LINQ語法來查詢它們。該框架會自動將您的LINQ查詢轉換爲針對CRM Web服務的FetchXML查詢。 DTO對象被創建爲部分類，因此您可以添加自己的邏輯來保存再生。

另一個提示：儘可能爲您的業務邏輯使用自定義工作流活動。不要將邏輯直接寫入XRMLinq生成的DTO，而應考慮創建一個自定義工作流程活動，以便在更新某些字段時觸發。這會強制您的業務邏輯運行，即使這些字段在系統中的其他位置得到更新（而不是通過您的自定義DTO邏輯）。它還爲您提供了一個不錯的排隊系統和故障恢復機制 - 如果您的自定義工作流程活動引發異常，則工作流程將「暫停」，直到您解決問題，此時您可以恢復失敗的工作流程。這隻適用於可以異步運行的業務邏輯，但對於同步邏輯，我仍然建議在將邏輯寫入DTO之前查看自定義插件。

希望有幫助！

來源

2010-07-07 20:21:44

這絕對有幫助！我必須研究自定義工作流程的想法，但這聽起來像是我們想要的東西。轉換仍處於早期設計階段，唯一確定的結果是：來自CRM的所有數據。 – Abel 2010-07-08 11:17:41

祝你好運 - 我們使用MSCRM 4作爲我們的企業框架並且喜歡它。這當然會讓你重新思考你現有的架構，但這對我們來說絕對是值得的。實際上，我花了我的一天寫商業邏輯，而不是現在的管道 - 聖盃！ :) – 2010-07-08 19:40:11

查看MS CRM SDK 4.0.12，也可以看到Reflector。他們走了很長的路要走一個合適的ORM，包括CRUD和Linq。 NH有許多微妙的（不太微妙的）差異，它還沒有被插件訓練，但至少你可以借鑑一些想法。

來源

2010-07-21 12:42:10 arch

好的建議，謝謝！ – Abel 2010-07-21 15:52:39

下面是一些很好的文章，詳細介紹了一個已在各種規模的項目上落後的SOA架構，該系列文章仍然被編寫，我相信它對您有用。

http://hubpages.com/hub/Building-Service-Orientated-Architecture

來源

2010-07-28 04:44:46 MetalLemon

推薦使用SOA（Microsoft CRM）從2層NHibernate遷移到3層的方法是什麼？

回答

相關問題