使用 StructureMap，这些项目组织之一是否比另一个更好？

Question

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

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

在我的第一次尝试中，我创建了一个项目 DependencyResolver，其中包含使用流畅接口初始化结构图的代码（当有人想要 IServiceA 时，给他们一个 ServiceX 的实例）。因为 DependencyResolver 的初始化需要从我的应用程序启动，所以我有一个从应用程序到 DependencyResolver 的引用，如下所示：

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

因此，我进一步采用了命名约定，深入到我正在使用的服务中，并且能够完全取消 DependencyResolver。此时，我完全依赖结构图扫描仪和命名约定来正确设置：

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

选项 2 消除了从应用程序到 DependencyResolver 的引用的需要，并依赖命名约定来访问该项目中的类，并且我仍然对所有剩余的设置具有高级别的控制权（但我现在依赖于 StructureMap）直接来自我的应用程序）。

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

那么，有谁对我在这方面有更多经验的人可以给我一些建议吗？
我是否应该避免从我的应用程序间接引用我的服务？如果是，这样做的真正好处是什么？我认为尝试用命名约定做所有事情只在简单的项目中才是明智的，对吗？
是否有一个标准模式来完成我在这里想做的事情？

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

Answer 1

将 StructureMap 的所有用法封装在组合根中，并在代码库的其余部分中使用构造函数注入。

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