例如，我有一个ASP.NET 5项目，一个业务层项目和一个数据访问项目，我有各种实体框架代码，如实体和上下文。在ASP.NET 5中，获取上下文设置和定位数据库主要文档建议我在我的StartUp.cs类中做这样的事情
services.AddEntityFramework()
.AddsqlServer()
.AddDbContext<BookContext>(options =>
{
options.UsesqlServer(Configuration.Get("Data:ConnectionString"));
});
这意味着我现在必须参考我的DAL，基本上我的UI层，根据各种专家和博客文章，这几年一直是不好的做法。
解决这个问题的一个方法是创建两个新的项目，一个是一个CompositeRoot项目，它包含工厂类，用于生成我的业务类，然后访问DAL，还有一个使用Configuration类的Utilities项目，其中有一个ConnectionString属性，可以传入我的上下文，然后使用内置的DI来连接所有东西，并避免在我的UI层中引用我的DAL。但是，我遇到了最新版本的Entity Framework(beta 7)的问题，因为它现在似乎无法在上下文的构造函数或可重写的OnConfiguration方法中指定连接字符串。此外，到目前为止，所有文件似乎都不关心这一点的混合。这是我们现在做的事情吗？相信开发人员不会直接在UI中做“参考”DAL类的“坏”事情？还是有一种模式，人们正在使用这种新的内置的DI /配置为ASP.NET 5保持SOLID？
解决方法
无论他们应用多少最佳做法和设计模式，每位建筑师都将为自己的想法辩护。有些会过热，而其他人会保持简单，完成工作。除此之外，预算，交货日期和工艺将直接影响您决定的建筑类型。
同样的规则适用于软件架构师。
我看到我在世界上有最好意图的建筑师的公平份额才意识到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层对Core，Data和Service有依赖关系。这个层是我配置我的DI东西的地方。
Web层没有依赖于数据层，而是开始使用，我正在使用Bootstrapper Nuget Package。
也许你可以实现与ASP.NET 5类似的东西
我喜欢微软(或任何人)创建一个更加面向企业级样本的工作项目模板，使用解耦方法，甚至像洋葱建筑样本。
最后，无论我认为像一个合理的解耦架构，对一些人来说可能太多了，而对别人来说还不够
随时分享您的发现，因为我很想知道您如何设法使其发挥作用。
