洋葱架构中的依赖性解决方案

Question

的洋葱结构是结构化的应用程序的方式来保持(例如在项目:关注和松耦合的分离http://onionarch.codeplex.com/).依赖注入/解析是此体系结构的一个关键方面,因为它用于将所有层绑定在一起.

上面的链接包含一个关于如何使用Onion分层构建ASP.NET MVC的示例应用程序.我非常喜欢它,但是大多数这些例子都使用了Ninject(我们都知道它很慢).我想知道是否有人可以详细说明如何将不同的DI工具(如SimpleInjector,Unity或Autofac)集成到洋葱项目中.

关键是所有层只有1个依赖关系(包括MVC项目),即Core层.除依赖性分辨率图层外,该图层可以引用所有图层.

我很难将MVC项目设置为启动项目,使用DI,而不是在MVC层中包含对DI工具的引用.

Answer 1

你的问题是

"如何将不同的DI工具(如SimpleInjector,Unity或Autofac)集成到洋葱项目中？"

我使用的是StructureMap而不是Ninject,它的集成方式应该适用于任何其他DI框架.

正如您所说,只有依赖关系解析层应该引用所有其他层,它是您的洋葱架构的最外层.好吧,为此,我创建了一个名为BootStrapper的项目.这是我引用StructureMap程序集的唯一项目.在这个项目的App_Start文件夹中,我有一个名为StructureMapMvc.cs的文件,如下所示:

[assembly: WebActivator.PreApplicationStartMethod(typeof(XXXX.BootStrapper.App_Start.StructuremapMvc), "Start")]

namespace XXXX.BootStrapper.App_Start
{
    public static class StructuremapMvc
    {
        public static void Start()
        {
            IContainer container = IoC.Initialize();
            System.Web.Mvc.DependencyResolver.SetResolver(new StructureMapDependencyResolver(container));
            GlobalConfiguration.Configuration.DependencyResolver = new StructureMapHttpDependencyResolver(container);
            ControllerBuilder.Current.SetControllerFactory(new StructureMapControllerFactory());
        }
    }
}

有趣的是:

[assembly: WebActivator.PreApplicationStartMethod(typeof(XXXX.BootStrapper.App_Start.StructuremapMvc), "Start")]

根据金块包的描述:

WebActivator是一个NuGet包,允许其他包在Web应用程序中执行一些启动代码.

很酷,对吧？您必须做的最后一件事是确保将BootStrapper项目程序集推送到Web应用程序的/ bin文件夹(使用post build action或OutputTo nugget包很容易设置).这将避免您在MVC项目中引用BootStrapper项目并破坏洋葱架构原则.

因此,有了所有这些,它完全遵循组合根模式,当您的应用程序启动时,模块将组合在一起.

希望这可以帮助!

Answer 2

请注意，我认为 Onion 架构（或者至少是您指出的示例实现，正如 @MystereMan 在评论中正确指出的那样）有一个您应该注意的问题点。

尽管该体系结构似乎更倾向于小型/集中的接口（通常只有一个成员），但这些服务的命名似乎表明情况并非如此。例如，在参考架构中，有一个IShippingService类。它只有一个成员，因此遵守接口隔离原则（这是很好的）。然而，名称“运​​输服务”表明它应该包含与运输相关的所有方法。这很容易就会有几十个。然而，向此接口添加成员会破坏接口隔离原则、单一职责原则(SRP) 和开闭原则(OCP)。如果有很多关系很少或没有关系（SRP）的方法，实现将会变得又大又难看。实施新的运输要求意味着添加成员，这会破坏 OCP。该接口有许多成员，而消费者通常只需要调用其中一个成员（低内聚性），这将使单元测试变得更加困难。

将其分解为所有一个成员的接口确实解决了部分问题（架构可能有这一意图），但这会留下大量彼此没有关系的接口，使得很难应用跨接口。减少对他们的关注（日志记录、监控、审计跟踪、验证、交易、容错等）。

这是否是一个问题取决于很多因素，但违反SOLID原则之一始终需要警惕。

因此，作为 Onion 架构的补充，我建议您阅读这篇文章。它描述了针对这一可能缺点的解决方案，并且可以应用于洋葱架构。