如何使框架和相關應用程序鬆散耦合？

Question

我有一個特定的案例，我想知道best practice的方式來處理它。

我製作了一個特定的.NET框架（web應用程序）。此Web應用程序通過以下方法充當許多其他Web應用程序的平臺或框架：

我們在獨立的解決方案中創建我們的依賴Web應用程序（用於項目業務的類，rdlc報告），然後構建它們。

之後，我們在框架中添加對結果dll的引用。

並創建用戶控制設置（每個相關的Web應用程序），並把它們放在一個文件夾中的框架它的自我。

它工作正常，但任何修改特定的用戶控件或到相關Web應用程序中的任何一個進行任何修改。我們必須再次添加引用併發布整個框架！

我想要做的是讓那些不同的web應用程序和框架鬆散耦合。所以我可以發佈框架並且只有一個，並且對用戶控件或不同Web應用程序的任何修改只是發佈更新的部分而不是整個框架。

如何重構我的代碼，所以我可以做到這一點？

最重要的事情是：

從未發佈整個框架如果任何相關應用程序的變化，只是發佈更新部分屬於該應用程序。

Answer 1

如果鬆耦合是你是什麼，培養一下「框架（Web應用程序）」，以作爲一個WCF Web服務。您的客戶端應用程序會將請求傳遞給您的Web服務，並以預定義對象的形式接收標準響應。

如果走這條路，我建議你實現一個額外的步驟：不要直接在客戶端代碼使用傳遞給您的客戶端應用程序中的對象。相反，在每個客戶端應用程序本地創建這些Web服務對象的版本，並在接收到您的Web服務響應對象時，將它們映射到本地對應的對象。我傾向於在我的客戶端解決方案中使用門面項目來實現此功能。 Facade處理對我的各種Web服務的所有調用，並且在每次調用時自動執行客戶端和服務對象之間的映射。這非常方便。

這樣做的原因是，你決定修改您的網絡服務供應對象的那一天，你只需要改變映射算法在客戶端應用程序......每一個客戶端解決方案的內部代碼保持不變。不要低估這可以節省多少工作！

開發WCF Web服務是一個相當大的課題。如果你有興趣，我推薦的書是Programming WCF Services。它爲來自.NET背景的人提供了一個很好的WCF開發介紹。

Answer 2

我完全同意levib，但我也有一些小技巧：

1. 作爲替代WCF（其瘋狂的配置需求），我會建議ServiceStack。像WCF一樣，它可以讓你接收請求並以預定義對象的形式返回響應，但是不需要代碼生成和最少的配置。它支持各種響應格式，如JSON，XML，JSV和CSV。這使得從f.ex中消費變得更容易。 JavaScript甚至移動應用程序。它甚至有MonoTouch和Mono for Android的二進制文件！它也是高度可測試和快速的！

2. 您的代碼的映射部分的一個好工具是AutoMapper，它允許您在單個位置設置所有映射，並通過調用簡單的方法將映射從一個對象類型映射到另一個。

檢查出來！ :)

Answer 3

幾十年的經驗說：避免框架，你不會有問題解決。

框架演變像癌症。通向地獄的道路鋪平了良好的意圖，這些良好意圖的很大一部分都體現在框架的巨大腫瘤中，所有這些都以潛在的再利用爲名，而這些從未真正發生過。

當談到面向對象和設計時，你會獲得一些經驗和知識，並且你會發現你的技術問題有無盡的解決方案，例如門面和紀念品，你有什麼，但它們不是解決你真正的問題的方法。另一件事，如果你正在使用MS技術，除了.NET提供的東西外，不要打擾任何東西。堅持MS神提供的東西，因爲只要你離題，並致力於一些內部框架，你的日子就有數。