Dependency injection 使用StructureMap，这些项目组织中的一个比另一个好吗？

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

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

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

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

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

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

选项2不再需要从应用程序引用DependencyResolver，并且依赖命名约定来访问该项目中的类，并且我仍然可以高度控制所有剩余的设置（但是我现在直接从应用程序依赖structureMap）

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

那么，有谁比我更有经验，能给我一些建议吗？
我应该避免从我的应用程序间接引用我的服务吗？如果是的话，这样做的真正好处是什么？ 只有在简单的项目中，尝试使用命名约定做任何事情都是明智的，这是对的吗？
有没有一个标准的模式来做我想做的事情

---

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

我在项目中使用了top设计，效果非常好

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

---

依赖项不应该像第二个选项中那样从两个地方解析，而不仅仅是通过第三个选项中的UI项目解析（如果交换UI项目并放入另一个项目会发生什么情况？）。

将StructureMap的所有用法封装在一个框架中，并在代码库的其余部分使用构造函数注入

---

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

如果我将其放在应用程序本身中，则我的应用程序必须直接引用项目中的所有程序集（即使用于访问这些程序集的所有代码都是通过接口完成的）为了设置容器。这看起来不太理想吗？也许这并不重要，但看起来组织得更好，使应用程序和域/业务层没有任何对第三方服务的引用。这就是为什么要将域模型放在单独的程序集中。这种架构分离需要更多的elab演说