使用 StructureMap，这些项目组织之一是否比另一个更好？
我开始在 Windows 应用程序项目上使用 StructureMap。在学习基础知识的过程中，我发现了两种方法来安排我的解决方案来实现相同的目标，我想知道是否有人可以评论这两种方法中的一种是否是更好的选择，以及为什么。
这里的目标是使用 IOC，以便我可以使用 2 个服务而不需要依赖它们。因此，我在业务层中创建了接口，然后在基础设施项目中实现了这些接口，并在那时包装了实际的服务。
在我的第一次尝试中，我创建了一个项目 DependencyResolver，其中包含使用流畅接口初始化结构图的代码（当有人想要 IServiceA 时，给他们一个 ServiceX 的实例）。因为 DependencyResolver 的初始化需要从我的应用程序启动，所以我有一个从应用程序到 DependencyResolver 的引用，如下所示：
因此我发现我可以删除对 DependencyResolver 的引用，并依赖 StructureMap扫描仪和命名约定在运行时获取该引用，所以我的设置如下所示：
因此，我进一步采用了命名约定，深入到我正在使用的服务中，并且能够消除DependencyResolver 全部在一起。此时，我完全依靠结构图扫描仪和命名约定来正确设置：
所以。我在这里，不太确定我应该如何看待这三个选项。选项 1 似乎不错，但由于使用了 StructureMap，我的 UI 间接引用了它不应该（直接）引用的所有内容。但是，我不确定这是否真的重要。
选项 2 消除了从应用程序到 DependencyResolver 的引用的需要，并依赖命名约定来访问该项目中的类，并且我仍然对所有剩余的设置具有高级别的控制权（但我现在依赖于 StructureMap）直接来自我的应用程序）。
选项 3 似乎是最简单的（只需以某种方式命名所有内容，然后扫描程序集），但这似乎更容易出错且脆弱。特别是如果我想做一些比 IServiceAbc => 更复杂的事情ServiceAbc。
那么，任何对我所做的事情有更多经验的人都可以给我一些建议吗？
我是否应该避免从我的应用程序间接引用我的服务？如果是，这样做的真正好处是什么？ 我认为尝试用命名约定做所有事情只在简单的项目中才是明智的，对吗？
是否有一个标准模式来完成我在这里想做的事情？
抱歉发了这么长的帖子..
I'm starting to work with StructureMap on a windows application project. In working on learning the basics, I found 2 ways to arrange my solution that accomplish the same goal, and I'm wondering if anyone can comment on if one of these 2 seems like a better option, and why.
The goal here was to use IOC so that I could use 2 services without taking dependencies on them. So I I created interfaces in my Business Layer, and then implemented those interfaces in my Infrastructure project and wrapped the actual services at that point.
In my fist attempt at this, I created a project DependencyResolver, which has code to intialize structuremap using the fluent interface (when someone wants IServiceA, give them an instance of ServiceX). Because the initialization of DependencyResolver needed to be kicked off from my app, I have a reference from the app to DependencyResolver like this:
So then I found that I could remove my reference to DependencyResolver, and rely on StructureMap scanner and naming conventions to get that reference at runtime, so then my setup looks like this:
So then, I took the naming conventions further, down into the services I was using, and was able to do away with the DependencyResolver all together. At this point, I am totally relying on the structuremap scanner and naming conventions to get things setup correctly:
So. Here I am, not quite sure how I should feel about these 3 options. Option 1 seems good, except I'm left with the UI indirectly referencing all the things that it shouldn't be referencing (directly) because of the use of StructureMap. However, I'm not sure if this really matters.
Option 2 removes the need for a reference from the app to DependencyResolver, and relies on naming conventions to access classes in that project, and I still have a high level of control over all the remaining setup (but I have now taken a dependence on structureMap directly from my application).
Option 3 seems the easiest (just name everything a certain way, and scan your assemblies), but that also seems more error prone, and brittle. Especially if I wanted to do something a little more complex than IServiceAbc => ServiceAbc.
So, can anyone who has a lot more experience with this stuff that I do give me some advice?
Should I be avoiding the indirect references from my App to my services, and if so, what are the real benefits of doing that?
Am I right that trying to do everything with naming conventions is only wise on simple projects?
Is there a standard pattern for doing what I'm trying to do here?
Sorry for the long post..
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
将 StructureMap 的所有用法封装在 Composition Root 中，并在整个过程中使用构造函数注入代码库的其余部分。
如果您愿意，可以在单独的程序集中实现组合根，但我通常更喜欢将其直接放在可执行文件本身中，然后在单独的库中实现所有应用程序逻辑。
Encapsulate all usage of StructureMap in a Composition Root and use Constructor Injection throughout the rest of your code base.
You can implement the Composition Root in a separate assembly if you'd like, but I usually prefer placing it directly in the executable itself, and then implement all of the application logic in separate libraries.
我在项目中使用了顶级设计，效果非常好。
依赖解析器或多或少是返回接口实例的工厂，结构映射不是实现这一点的一种方法吗？在这种情况下，我将通过一个中心位置的依赖解析器请求任何项目。然后，还可以删除结构图并添加另一个服务定位器（unity、温莎城堡等），而无需更改应用程序的任何其他内容。
依赖关系不应该像第二个选项中那样从两个地方解决，而不仅仅是通过第三个选项中的 UI 项目来解决（如果您换出 UI 项目并放入另一个不同的项目，会发生什么？）。
I have used the top design on projects and it work extremely well.
Dependency resolvers are more or less factories to return interface instances, isn't structure map just one way to implement this? In that case I would make request for any item via the dependency resolver at one central place. Then it is also possible to remove structure map and add another service locator (unity, castle windsor etc.) in without changing anything else about your app.
Dependencies should not be resolved from two places as seen in your second option, and not only via the UI project in the third option (what happens if you swap out your UI project and put a different one in then?).