我正在研究一個相當直接的多層應用程序(WPF,WCF,EF 4和SQL)。就架構而言,我們計劃包括一個「共同」項目,該項目將包括實體和服務合同。WCF N層體系結構
在單獨的程序集中擁有實體和服務合同有什麼優點/缺點嗎?或者將它們放在一起通常很好?
我有興趣聽到別人的意見。
謝謝!
我正在研究一個相當直接的多層應用程序(WPF,WCF,EF 4和SQL)。就架構而言,我們計劃包括一個「共同」項目,該項目將包括實體和服務合同。WCF N層體系結構
在單獨的程序集中擁有實體和服務合同有什麼優點/缺點嗎?或者將它們放在一起通常很好?
我有興趣聽到別人的意見。
謝謝!
在一個單獨的程序集中擁有合同,可以讓您通過向開發人員提供合同程序集來向不同程序集中的不同實體注入能力,並且可以實施它併爲您提供一個可放入其中的dll項目文件夾,並注入到它使用IoC框架像StructureMap不重建,
具有包含實體扳平合同的實現同樣的組裝合同...
這正是我如何構成的爲我設計的電子商務N層應用程序設計。
有兩個通用庫 - 一個用於DTO和另一個用於接口。
然後客戶端和服務器包含這些librarues,服務代理使用常見類型生成。
這裏的主要優點是易於編譯 - 當您更改接口時,您不必重新創建代理,客戶端和服務器會自動更新。
我也有一個實用程序應用程序,其中包含我需要的所有幫助類型的東西。
編輯:對不起,只是重新讀你的問題。在我的情況下,我有多個接口庫 - 一個用於工作流程庫(具有組合的接口),另一個用於服務(正在組成工作流操作的東西)
所以在我的情況下,保持它們的分離是有意義的。
如果你只有一組接口,並且這些接口都使用你的DTO,那麼沒有理由把它們分成兩個庫 - 一個就足夠了。考慮一下,如果你將來可能需要在更多的接口庫之間共享你的DTO,在這種情況下,應該保持DTO從一開始就與接口分離。
如果您將RESTful體系結構與其他.NET平臺消費者一起使用 - 將Service Contracts放在單獨的程序集(Shared)中會很有幫助,以便您可以輕鬆地與RESTful消費者共享您的操作和數據合同,而不會泄露任何不必要的數據訪問組件到您的客戶。
我建議您保持數據訪問和服務合同隔離出於這個原因。
感謝您的回覆。如果合同和實體在同一個程序集中,那麼它們肯定會緊密結合在一起。 – 2012-02-13 15:51:41