2011-02-09 70 views
1

以傳統的思維方式(記得DNA?),我們應該通過將圖層分離爲服務來構建我們的應用程序。當實現一個ASP.NET MVC應用程序時,爲什麼你應該真的實現一個額外的服務並將你的WCF引用包裝到一個單獨的dll中,而不是讓Web應用程序直接引用WCF?爲什麼不從web項目引用wcf服務?

我能想到的兩個參數,並在這些的一些想法:

  • 請注意,一旦發生代碼
  • 可重複使用的服務等時(當然,這仍然是當你有WCF進行!)系統需要的服務(當然,如果其內部的應用程序嗎?)

在另一方面,人們可能會爭論已有的架構作爲執行層的很多僅僅帶來更多的複雜性解決方案並不會產生預期的好處。

回答

1

我其實並不是引入額外的dll只是「因爲」的粉絲。到過那裏; ot上面有依賴圖的T恤。如果您無法在您的環境/內容中明確定義好處,那麼請執行最簡單的操作 - 這可能是Web應用程序的參考。

我聽說過允許重複使用的觀點,但是爲了反擊:soap/mex已經非常明確地定義了這一點。另一個論點是可測試性,隔離性,分離性等。這一切都取決於這些給你多少好處(或者說:你的團隊)在你的用法。

一個非常有效情況下,在這裏一個單獨的DLL時(主要爲內部應用程序)要共享的WCF服務器和客戶端之間的DTO庫,這樣既具有豐富的對象,而不是簡單的陰影。我從(基調)收集到,這不適用於這種情況。

+0

這是一個asp.net mvc應用程序,其服務層使用針對EF4的POCO類。 – Andreas 2011-02-09 19:39:55