dependency-injection - 使用 StructureMap，这些项目组织中的一个是否比另一个更好？

Question

我开始在 Windows 应用程序项目上使用 StructureMap。在学习基础知识的过程中，我发现了两种方法来安排实现相同目标的解决方案，我想知道是否有人可以评论这两种方法中的一种是否是更好的选择，以及为什么。

这里的目标是使用 IOC，以便我可以使用 2 个服务而不依赖它们。所以我在我的业务层中创建了接口(interface)，然后在我的基础设施项目中实现了这些接口(interface)，并在那时包装了实际的服务。

在我的第一次尝试中，我创建了一个项目 DependencyResolver，它具有使用 fluent 接口(interface)初始化结构映射的代码(当有人想要 IServiceA 时，给他们一个 ServiceX 的实例)。因为需要从我的应用程序中启动 DependencyResolver 的初始化，所以我有一个应用程序对 DependencyResolver 的引用，如下所示:



然后我发现我可以删除对 DependencyResolver 的引用，并依靠 StructureMap 扫描器和命名约定在运行时获取该引用，所以我的设置如下所示:



因此，我将命名约定进一步深入到我正在使用的服务中，并且能够一起取消 DependencyResolver。在这一点上，我完全依靠结构图扫描仪和命名约定来正确设置:



所以。我在这里，不太确定我应该如何看待这三个选项。选项 1 似乎不错，除了我留下的 UI 间接引用了由于使用 StructureMap 而它不应该(直接)引用的所有内容。但是，我不确定这是否真的很重要。

选项 2 消除了从应用程序引用 DependencyResolver 的需要，并依赖命名约定来访问该项目中的类，并且我仍然可以对所有剩余设置进行高度控制(但我现在依赖于 structureMap直接来自我的应用程序)。

选项 3 似乎是最简单的(只需以某种方式命名所有内容，然后扫描您的程序集)，但这似乎也更容易出错且脆弱。特别是如果我想做一些比 IServiceAbc => ServiceAbc 更复杂的事情。

那么，任何对我做的东西有更多经验的人能给我一些建议吗？
我是否应该避免从我的应用程序对我的服务的间接引用，如果是这样，这样做的真正好处是什么？
我是否正确地尝试使用命名约定来做所有事情仅在简单项目上才是明智的？
是否有标准模式来做我在这里尝试做的事情？

抱歉发了这么长的帖子。。

Answer 1

将 StructureMap 的所有用法封装在 Composition Root 中并在其余代码库中使用构造函数注入(inject)。

如果愿意，您可以在单独的程序集中实现 Composition Root，但我通常更喜欢将其直接放在可执行文件本身中，然后在单独的库中实现所有应用程序逻辑。