使用StructureMap，这些项目组织之一是否优于另一个？

Question

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

这里的目标是使用IOC，这样我就可以使用2个服务而不依赖于它们。所以我在业务层中创建了接口，然后在我的Infrastructure项目中实现了这些接口，并在那时包装了实际的服务。

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

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

那么，我进一步采用了命名约定，直到我正在使用的服务，并且能够一起取消DependencyResolver。此时，我完全依赖于结构图扫描程序和命名约定来正确设置：

因此。在这里，我不太确定我应该如何看待这3个选项。选项1似乎很好，除了我留下了UI，因为使用了StructureMap而间接引用了它不应该引用的所有东西（直接）。但是，我不确定这个真的是否重要。

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

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

那么，任何对这些东西有更多经验的人都可以给我一些建议吗？ 我是否应该避免从我的应用程序到我的服务的间接引用，如果是这样，这样做的真正好处是什么？ 我是对的，尝试用命名约定做所有事情只对简单项目有用吗？ 做我想做的事情有标准模式吗？

很抱歉很长的帖子..

Answer 1

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

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

Answer 2

我在项目中使用了顶级设计，但效果非常好。

依赖解析器或多或少是工厂返回接口实例，不是结构图只是实现这一点的一种方式吗？在这种情况下，我会通过依赖解析器在一个中心位置请求任何项目。然后还可以删除结构图并添加另一个服务定位器（unity，castle windsor等），而无需更改有关您的应用程序的任何其他内容。

不应该从第二个选项中看到的两个地方解析依赖关系，而不仅仅是通过第三个选项中的UI项目解决（如果换掉你的UI项目并在其中放入另一个项目会怎样？）。 / p>