2017-02-16 70 views
2

我有一個三層應用程序。每個部分都與我的解決方案的另一部分有依賴關係。我曾經在MVC項目中實現了IDependencyResolver。這是一種錯誤的方式,因爲它會導致違反層分離的架構規則。我的MVC項目引用了DAL層。這是一種糟糕的編碼習慣。我知道我可以創建一個單獨的類庫項目。它將引用我的解決方案的任何其他項目。它將解決所有的依賴關係。我聽說這不是最好的方法。有一個更好的辦法。我的解決方案的每個項目都應該解決它擁有的依賴關係。我不明白如何把它放在一起。所以我發現這篇有用的文章:Dependency Injection Best Practices in an N-tier Modular Application,但它似乎太困難和複雜。有另一種方法嗎?我有一個類似的解決方案結構。 UserRepository返回一個請求的用戶。如何在N層圖層應用程序中實現IDependencyResolver?

public interface IUserRepository 
    { 
     IEnumerable<UserEntity> GetAll(); 
    } 

    public class UserRepository : IUserRepository 
    { 
     public IEnumerable<UserEntity> GetAll() 
     { 
      // some code 
     } 
    } 

UserService可以有幾個不同的依賴關係。

public interface IUserService 
    { 
     IEnumerable<UserModel> GetAll(); 
    } 

    public class UserService : IUserService 
    { 
     private readonly IUserRepository userRepository; 
     private readonly ISecondRepository secondRepository; 
     private readonly IThirdRepository thirdRepository; 

     public UserService(IUserRepository userRepository, ISecondRepository secondRepository, IThirdRepository thirdRepository) 
     { 
      this.userRepository = userRepository; 
      this.secondRepository = secondRepository; 
      this.thirdRepository = thirdRepository; 
     } 

     public IEnumerable<UserModel> GetAll() 
     { 
      // some code 
     } 
    } 

最後UserController構造函數可能有很多不同的依賴關係。

我的問題是關於什麼是正確的,最簡單的方法來解決這些依賴關係,避免違反架構規則?

enter image description here

+0

想想運行時的層分離規則。當應用程序由依賴解析器引導時,如果您已正確映射解析器,它將遵循這些規則。看看這個答案http://stackoverflow.com/questions/40401900/bootstrapping-unity-composition-root-location/40403875#40403875 –

+0

可能重複[Ioc/DI - 爲什麼我必須引用所有層/組件in entry application?](http://stackoverflow.com/questions/9501604/ioc-di-why-do-i-have-to-reference-all-layers-assemblies-in-entry-application) – NightOwl888

回答

2

喜歡你說可以創建附加層,其將組成依賴性,這就是所謂的組合物根Check this SO question。 在你的情況下,組合根是MVC項目。 從我的角度來看,引用DAL並不是那麼糟糕的做法。當我們談論依賴關係時,應該畫線。對於我來說,當我們談論依賴關係時,並不是那麼重要的dll引用,而是使用的類型(接口或具體)。正如你所知,DI是關於取決於具有實際價值的抽象的。因此,只要您僅依賴DAL中的接口,您的代碼仍然可以。

在實踐中,當dll依賴關係變得過於複雜時,我將其他項目用作組合根。

關於你的問題關於圖層應該如何解決它們的依賴關係。我不確定這是否是你的意思,但是在DDD中練習BLL來自定義層中的基礎結構接口(如存儲庫)。這種方式依賴圖是崇敬。現在基礎設施層(DAL)只定義BLL提供的接口的具體實現,並且再次在組合根中連接一切。

第一種方法其中基礎結構層定義了接口並且實現具有無依賴性的優點,這對於跨不同項目的重用是合適的。但請記住,在大領域工作有時可能會導致無法形容的代碼。

作爲DDD的第二種方法最重要的是域,所以一切適用於域。根據我的經驗,圍繞該域的結構良好的圖層是最佳選擇。這個apporach讓你的代碼更清楚地解釋你爲這個域所解決的問題。 我不知道我是否正確地表達了我的自我。

作爲最後說明我會建議你DDD的方法,如果使用這只是一個學習experiances。學習新東西是最好的選擇。

我不是這個領域最有經驗的人。 我是程序員大約3年,並主要在中型項目上工作,所以我的意見並不穩固;]