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

Question

由于我想使用新的内置依赖注入(inject)，我正在努力寻找一种优雅的方法来将我的 DAL 层与 ASP.NET 5 中的 MVC/UI 层分开。

例如，我有一个 ASP.NET 5 项目、一个业务层项目和一个数据访问项目，其中有各种 Entity Framework 代码，例如实体和上下文。在 ASP.NET 5 中，为了设置上下文并定位数据库，主要文档建议我在 StartUp.cs 类中执行类似的操作

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

这意味着我现在必须在基本上是我的 UI 层的地方引用我的 DAL，根据各种专家和博客文章的说法，多年来这一直是不好的做法。

我解决这个问题的一种方法是创建两个新项目，一个是 CompositeRoot 项目，其中包含工厂类来生成我的业务类，然后访问 DAL，还有一个带有配置类的实用程序项目，其中有一个 ConnectionString 属性，我可以将其传递到我的上下文中，然后我使用内置的 DI 连接所有内容并避免在 UI 层中引用我的 DAL。但我遇到了最新版本的 Entity Framework (beta 7)的问题，因为现在似乎无法在上下文的构造函数或可重写的 OnConfiguration 中指定连接字符串方法。另外，到目前为止的所有文档似乎根本不关心这种混合的问题。这就是我们现在做事的方式吗？相信开发人员不会做“坏”事，比如直接在 UI 中引用 DAL 类吗？或者人们是否正在采用一种模式来让 ASP.NET 5 的新内置 DI/配置保持稳定？

Answer 1

如果您要求 10 位土木建筑师为您 build 一座桥梁，您最终会得到 10 种不同的建筑。没有一个会是相同的，也没有一个会比另一个更好。

无论他们应用了多少最佳实践和设计模式，每个架构师都会证明他们的想法是正确的。有些人会过于热心，而另一些人会保持简单并完成工作。除此之外，预算、交付日期和工艺将直接影响您决定的架构类型。

同样的规则也适用于软件架构师。

我见过很多架构师怀着世界上最好的意图，却发现 UI 层依赖于 DAL。也许这背后的原因是:

• 他们没有想到
• 他们并不真正关心这个
• 它促进了 DI，因为你可以看到每一层，而这又使得它成为可能 轻松将接口(interface)映射到其实现。

回到 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 层不依赖于Data 层，为了开始工作，我使用了 Bootstrapper Nuget Package .

也许您可以使用 ASP.NET 5 实现类似的目标

我希望 Microsoft(或任何人)创建一个工作项目模板，该模板更适合使用解耦方法甚至洋葱架构示例之类的企业级示例。

最后，无论我认为合理的解耦架构对于某些人来说可能太多，而对其他人来说却不够......

请随意分享您的发现，因为我很好奇您是如何让它发挥作用的。