2014-04-10 17 views
0

我正在爲服務器層使用WCF,實體框架和POCO類構建N層應用程序,而對於客戶端,我使用WPF和MVVM模式。 服務器端代碼我把它分爲4個項目:NTier使用WCF服務的設計建議

* Data Layer(DAL -> EF) 
* Model Layer (POCO's classes) 
* Business Layer (BAL) 
* Service Layer (WCF) 

對於所有的服務器層之間,並與WCF客戶端i在模型定義一個接口交際,即我的每一層上實現。 我將自己編寫所有代碼,從DAL到表示層,因此需要關注的分離是可取的,但不是必需的。

所以我的問題:

1)這樣的設計是否合理beeing自己的所有代碼的作家嗎?

2)爲簡單起見,我應該減少工件數嗎?

3)在每層上有一個接口實現一個好主意嗎?因爲我發現自己必須爲每種新方法編寫非常相似的代碼3次。事情是這樣的:

在WCF服務:

public IEnumerable<Clientes> GetClients() 
    { 
     BusinessLayer.Ohmio _cli = new BusinessLayer.Ohmio(); 
     return _cli.GetClients(); 
    } 

在業務:

public IEnumerable<Clientes> GetClients() 
    { 
     DataLayer.Ohmio bn = new DataLayer.Ohmio(); 
     return bn.GetClients(); 
    } 

上的數據:

public IEnumerable<Clientes> GetClients() 
    { 
     using (var context = new OhmioEntities()) 
     { 
      var _clients= context.Clientes.ToList();     
      return _clients; 
     } 
    } 

是看到另外兩個問題與介面方法:

1)然後我使用相同的接口爲comuniccate服務器端圖層和wcf客戶端,所以數據類型需要相同。

2)在一個複雜的應用程序的情況下(如我建立的那個),接口和所有實現的類將是巨大的!因爲他們需要項目中所有對象的所有方法!

這種類型的病例有更好的解決方案嗎?任何建議將被認真考慮!!!!謝謝!

+1

所有的圖層都沒有添加任何值,它們不會執行任何操作。只有一次實現的接口幾乎沒有用處。花時間在其他地方,而不是增加人爲的複雜性。 – usr

+0

這就是我的觀點。在某些情況下,BusinessLayer會將轉化添加到數據中。但是在大多數情況下,信息從一層傳遞到另一層而沒有任何改變但是,這應該是關於n層設計的想法:將數據庫邏輯與業務分開等。也許這種設計只有在很多人從事這種項目時纔有意義。我試着在這裏遵循一個很好的編程模式。 – ericpap

+1

太多的圖層會殺死你的應用程序。小心。 +1 for @usr – DarthVader

回答

1

接口和抽象構建了依賴注入(控制反轉)的基礎,允許獨立測試組件和層。像您一樣分離層可以幫助您減少複雜性並提高可測試性,可維護性等問題分離。

對於小型和簡單的應用程序,這種努力可能不值得。但是,越大和越複雜的應用程序越容易將最佳實踐和設計原則和模式考慮在內。

爲了避免建立與所有層的解決方案和寫所有的鍋爐電鍍代碼,你很可能有興趣嘗試了N-Tier Entity Framework這是一個開源框架,完美匹配你描述的場景的努力。在任何情況下,您都應該看看它的documentation,其中包含有關幫助您設計此類解決方案的架構注意事項的專用部分。

+0

謝謝。我看看! – ericpap