為了更好有效利用松耦合的特點，以及插件化應用的特點，我對整個WCF開發架構進行了一個大的調整，以便更好整合及利用好的特點。如下圖所示，插件化應用架構的啟動子產品，它除了依賴基礎服務子產品中（包括權限管理子產品和字典子產品），其他的子產品如WCF服務子產品、主業務插件子產品A（主業務子產品B）等都是通過配置方式實作對接的，他們之間沒有明顯的耦合關系。
整個項目工程的布局如下所示，其中BaseUIDx為基礎界面類，友善各個插件子產品重用而分離出來的。其他子產品的功能如上圖所示。
主業務插件子產品是指各種各種的插件化業務子產品，他們本身包含有界面部分、WCF服務調用、以及業務邏輯等内容。
為了更好分離WCF服務的部署和WCF服務邏輯（這也是最佳實踐），實作更好的代碼控制和重用，WCF項目的架構關系設定成如下所示。
其中WHC.WareHouseMis.WCFLibrary是整個WCF服務的業務邏輯子產品，它囊括了統一調用接口Facade層、WCF業務實作WCFLibrary層、BLL業務層、資料接口IDAL層、資料通路實作DAL層、實體類Entity層。
當然，以上的關系不需要手工來做這些繁瑣的代碼對應關系，隻需要設計好表後，使用代碼生成工具Database2Sharp一鍵生成就可以了，其中很多項目關系已經生成好了，增量開發的時候，重新引用下檔案關系即可。
而且整個ＷＣＦ不在使用在界面層直接引用WCF服務的方式，而采用了自定義的用戶端信道(允許從自定義的配置檔案中加載)方式實作對應WCF服務用戶端代理類的建立。
以WCF的調用類ItemDetailCaller為例，使用代碼生成工具生成的代碼，它已經繼承了某個接口IItemDetailService服務基類了，并給它指定了具體的WCF服務節點即可，如下代碼所示。
實作接口IItemDetailService的函數很有規律，使用下面類似的代碼即可。
這樣進行了包裝後，我們使用WCF服務就好像之前的Winform開發架構使用BLLFactory的方式一樣了，WCF服務調用示例代碼如下所示。