ASP.NET 5 / ASP.NET Core 1中關注點和n層架構的分離

asp.net asp.net-core asp.net-core-mvc dependency-injection entity-framework-core

由於我想使用新的內置依賴注入,我很難找到一種優雅的方法來保持我的DAL層與ASP.NET 5中的MVC / UI層分離。

例如,我有一個ASP.NET 5項目,一個業務層項目和一個數據訪問項目,其中我有各種實體框架代碼,如實體和上下文。在ASP.NET 5中設置上下文並定位數據庫主要文檔建議我在StartUp.cs類中執行類似的操作

services.AddEntityFramework()
    .AddSqlServer()
    .AddDbContext<BookContext>(options =>
    {
        options.UseSqlServer(Configuration.Get("Data:ConnectionString"));
    });

這意味著我現在必須在基本上我的UI層中引用我的DAL,根據各種專家和博客文章,多年來一直是不好的做法。

我解決這個問題的一種方法是創建兩個新項目,一個是CompositeRoot項目,它包含生成業務類的工廠類,然後訪問DAL,還有一個帶有Configuration類的Utilities項目,其中的ConnectionString屬性是I可以傳入我的Context,然後我使用內置的DI來連接所有內容並避免在我的UI層中引用我的DAL。但是我遇到了最新版本的Entity Framework(beta 7)的問題,因為現在似乎無法在上下文的構造函數或可重寫的OnConfiguration方法中指定連接字符串。此外,到目前為止,所有文檔似乎都不關心這種混合問題。這只是我們現在做事的方式嗎?相信開發人員不會做直接在UI中引用DAL類的“壞”事情?或者是否有一種模式,人們正在使用這種新的內置DI /配置為ASP.NET 5保持SOLID?

熱門答案

如果你讓10位民用建築師為你建造一座橋樑,那麼你最終會擁有10種不同的架構。沒有一個會是相同的,沒有一個會比另一個更好。

無論他們應用了多少最佳實踐和設計模式,每個架構師都會證明他們的想法是正確的。有些人會過於熱心,有些則會保持簡單並完成工作。除此之外,預算,交付日期和工藝將對您決定的建築類型產生直接影響。

同樣的規則適用於軟件架構師。

我已經看到了我在世界上擁有最佳意圖的建築師的公平份額,只是意識到UI層依賴於DAL。也許這背後的原因是:

  • 他們沒有想到這一點
  • 他們並不真正關心它
  • 它有助於DI,因為您可以看到每個層,從而可以輕鬆地將接口映射到其實現。

回到MVC 5,我有以下幾層:

-Contoso.Core (Class Library)
-Contoso.Data (Class Library)
-Contoso.Service (Class Library)
-Contoso.Web (asp.net MVC 5)
-Contoso.Web.Configuration (Class Library)

Web.Configuration層依賴於CoreDataService 。這層是我配置我的DI東西的地方。

Web層沒有對Data層的依賴,並且為了開始工作,我使用的是Bootstrapper Nuget Package

也許你可以用ASP.NET 5實現類似的功能

我喜歡微軟(或任何人)創建一個工作項目模板,該模板更適合企業級樣本,使用解耦方法甚至像Onion Architecture樣本。

最後,無論我認為合理的解耦架構對某些人來說可能過多,而對其他人來說則不夠......

隨意分享您的發現,因為我很想知道您是如何設法使其發揮作用的。




許可下: CC-BY-SA with attribution
不隸屬於 Stack Overflow
這個KB合法嗎? 是的,了解原因
許可下: CC-BY-SA with attribution
不隸屬於 Stack Overflow
這個KB合法嗎? 是的,了解原因