Structuremap 和引用，什么是最佳实践？答案

【问题标题】：Structuremap and references, what is best practices?Structuremap 和引用，什么是最佳实践？
【发布时间】：2010-07-15 08:40:56
【问题描述】：

我是第一次尝试使用结构图。我以前使用过 ioc 容器，但总是使用 xml 配置。由于结构图通过代码使用配置（我知道它也可以在 xml 中完成，但大多数示例都是通过代码使用配置）我遇到了一些参考问题。

让我们使用以下示例（不是真实示例）：

3 个程序集。

数据层业务层服务

BusinessLayer 引用 DataLayer（因此它可以检索数据） DataLayer 和 BusinessLayer 都引用了 Services 程序集，因为它包含用于记录的代码。

我希望 Log 组件由 StructureMap 管理，以便我可以更改日志组件。

在业务层中，还有一些由 StructureMap 提供服务的组件。

所以我的问题是现在。

我在哪里放置结构图配置？

如果我将它放在 BusinessLayer 中，DataLayer 将无法使用 Log 组件（因为对业务层的引用将在循环引用中解析）。我不能把它放在Services项目中，因为BusinessLayer中还有一些组件（并且业务层有对服务程序集的引用）。

我希望我已经对自己进行了充分的解释。这里的主要问题是 StructureMap 在配置之前需要对程序集的引用，我发现使用它有点问题。我做错了吗？

【问题讨论】：

标签： c# dependency-injection inversion-of-control structuremap

【解决方案1】：

容器配置必须在顶层，在表示层：网站、Web 服务、控制台应用程序、Windows 应用程序或 Windows 服务。因此，您可以在任何地方注入所需的一切。

【讨论】：

中肯的建议，但如果我有多个“顶层”怎么办？例如。在我的项目中，我都有一些在 SharePoint 中运行的工作流（没有 UI）和 Web 项目中的一些 WebPart（它是一个共享点项目）。
这取决于这些工作流程的运行方式。您可能需要的不仅仅是一个容器。我有一个包含一些 Web 服务的 Web 项目。我有一个用于 Web 应用程序的容器和两个用于 Web 服务的容器。这些容器是包含常见事物（日志记录等）的公共容器的子容器（Unity 允许子容器，我不知道 StructureMap）。
好的，谢谢。我想我的“主要”问题中的一个隐含问题是拥有多个容器是否“好”。我总是可以使用寄存器来包含通用配置。

【解决方案2】：

我将编程配置（IoC 或任何其他）置于进程级别的引导方法中。因此，在客户端/服务器系统中，客户端进程对于它需要的任何配置都有自己的引导程序，而服务器进程对于它需要的任何配置都有一个单独的引导程序方法（这可能是重用代码，或者它们可能是非常不同的要求）。例如，客户端引导程序不需要知道 DAL 配置，服务器引导程序不需要知道任何 UI 配置。

【讨论】：