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

Question

由于我想使用新的内置依赖注入,我很难找到一种优雅的方法来保持我的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属性,我可以传入我的上下文,然后我使用内置的DI来连接所有内容并避免在我的UI层中引用我的DAL.但我遇到了最新版本的Entity Framework(beta 7)的问题,因为它现在似乎无法在上下文的构造函数或可重写中指定连接字符串OnConfiguration方法.此外,到目前为止,所有文档似乎都不关心这种混合问题.这就是我们现在做事的方式吗？相信开发人员不会做直接在UI中引用DAL类的"坏"事情？或者是否有一种模式,人们正在使用这种新的内置DI /配置为ASP.NET 5保持SOLID？

Answer 1

如果您要求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图层依赖于Core,Data和Service.这层是我配置我的DI东西的地方.

该Web层没有对Data图层的依赖,并且启动了东西,我使用的是Bootstrapper Nuget Package.

也许你可以用ASP.NET 5实现类似的功能

我希望微软(或任何人)能够创建一个工作项目模板,该模板更适合企业级样本,使用解耦方法甚至像Onion Architecture样本.

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

随意分享您的发现,因为我很想知道您是如何使其成功的.

Answer 2

您也许可以使用Service Locator来解决这个问题。

例如，您的root/core/abstractions项目中有一个接口：

public interface IServiceConfiguration
{
    void ConfigureServices(IServiceCollection services, IConfigurationRoot configuration);
}

在 StartUp.cs 中，找到实现 IServiceConfiguration 的所有类型并使用它来注册外部服务。

public void ConfigureServices(IServiceCollection services)
{
    var currentAssembly = typeof(Startup).Assembly;

    // Limit to project assemblies
    var @namespace = currentAssembly.FullName.Split(',')[0].Split('.')[0];
    var assemblies = currentAssembly.GetReferencedAssemblies()
                            .Where(a => a.Name.StartsWith(@namespace, StringComparison.Ordinal))
                            .Select(a => Assembly.Load(a));

    foreach (var assembly in assemblies)
    {
        // Assembly.ExportedTypes is not supported in dnxcore50 so you need to take it off your frameworks node in project.json.
        foreach (var config in assembly.ExportedTypes.Where(t => typeof(IServiceConfiguration).IsAssignableFrom(t) && !t.IsAbstract))
        {
            ((IServiceConfiguration)Activator.CreateInstance(config)).ConfigureServices(services, Configuration);
        }
    }

    // More service registrations..
}

在您的 DAL 中，您可以添加一个将注册 EF 的类：

public sealed class EntityFrameworkServiceConfiguration : IServiceConfiguration
{
    public void ConfigureServices(IServiceCollection services)
    {
        services.AddEntityFramework()
                    .AddSqlServer()
                    .AddDbContext<BookContext>(options =>
                    {
                        options.UseSqlServer(Configuration.Get("Data:ConnectionString"));
                    });
    }
} 

但并不是每个人都需要这种类型的解耦。在某些方面，将所有内容注册到 StartUp.cs 中更有意义。无论如何，您都会在 Web 项目中引用您的 DAL（除非一切都是通过动态发现），这意味着它已经了解有关您的 DAL 的一些信息。