使用StructureMap，这些项目组织之一比另一个更好吗？ [英] Using StructureMap, is one of these project organizations better than another?

问题描述

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

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

创建了一个项目DependencyResolver，该代码具有使用流畅接口初始化结构图的代码（当有人需要IServiceA时，请给他们一个ServiceX实例）。因为需要从我的应用程序开始DependencyResolver的初始化，所以我从应用程序获得了对DependencyResolver的引用，如下所示：

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

然后，我将命名约定更进一步，深入到我正在使用的服务中，并且能够消除依赖关系一起ver。在这一点上，我完全依赖于结构图扫描仪和命名约定来正确地设置内容：

如此。在这里，我不太确定我对这三种选择的感觉。选项1看起来不错，但由于使用了StructureMap，我只能让UI间接引用所有不应该（直接）引用的内容。但是，我不确定这是否真的很重要。

选项2消除了从应用程序到DependencyResolver的引用的依赖，并依赖关于访问该项目中的类的命名约定，我仍然对其余所有设置都拥有高度的控制权（但是现在我直接从我的应用程序中获得了对structureMap的依赖）。

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

因此，任何对我有很多经验的人都可以给我

我应该避免从App间接引用我的服务吗？如果是，这样做的真正好处是什么？
我想对所有使用命名约定进行操作仅在简单项目上才是明智的做法吗？

是否有标准的模式可以执行我在这里要做的事情？

很长的帖子。

解决方案

封装所有用法组成根中的结构映射，并在其余的整个过程中使用构造函数注入代码库。

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

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..

解决方案

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.

这篇关于使用StructureMap，这些项目组织之一比另一个更好吗？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！