ASP.NET 5/ASP.NET Core中的关注点和n层架构的分离1

我正在努力寻找一种优雅的方式来保持我的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"));
    });

这意味着我现在必须参考我的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类似的东西

我喜欢微软(或任何人)创建一个更加面向企业级样本的工作项目模板，使用解耦方法，甚至像洋葱建筑样本。

最后，无论我认为像一个合理的解耦架构，对一些人来说可能太多了，而对别人来说还不够

随时分享您的发现，因为我很想知道您如何设法使其发挥作用。

（编辑：安卓应用网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!