我正在爲服務器層使用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)在一個複雜的應用程序的情況下(如我建立的那個),接口和所有實現的類將是巨大的!因爲他們需要項目中所有對象的所有方法!
這種類型的病例有更好的解決方案嗎?任何建議將被認真考慮!!!!謝謝!
所有的圖層都沒有添加任何值,它們不會執行任何操作。只有一次實現的接口幾乎沒有用處。花時間在其他地方,而不是增加人爲的複雜性。 – usr
這就是我的觀點。在某些情況下,BusinessLayer會將轉化添加到數據中。但是在大多數情況下,信息從一層傳遞到另一層而沒有任何改變但是,這應該是關於n層設計的想法:將數據庫邏輯與業務分開等。也許這種設計只有在很多人從事這種項目時纔有意義。我試着在這裏遵循一個很好的編程模式。 – ericpap
太多的圖層會殺死你的應用程序。小心。 +1 for @usr – DarthVader