StructureMap n层应用程序

Question

我正在尝试将StructureMap实现到我的ASP.Net MVC 3应用程序中。我的架构遵循n层方法，我的UI层与我的服务层进行对话，后者又与我的业务层进行对话，业务层又与存储库层进行对话。我有数据合同，代表流经所有层的数据。

我的UI层应该只知道服务层。我的UI不应该知道或关心业务，更不用说存储库或数据层。每个层都是它自己的程序集，我正在使用构造函数依赖注入来注入必要的实例（即我将业务对象注入到我的服务构造函数中并将存储库对象注入到业务构造函数中）。

因此，如果我的层位于单独的程序集中，并且Structure Map所在的UI程序集不知道较低的层，那么如何配置结构图？我不愿意在我的UI层中为位于服务层后面的所有“较低”层创建引用。如果我这样做，那么这可能会为UI打开直接与数据库直接对话的大门。

请帮忙。

由于

汤姆

Answer 1

  

我不愿意在我的UI层中为位于服务层后面的所有“较低”层创建引用。如果我这样做，那么这可能会为UI打开直接与数据库直接对话的大门。

您应该将所有 lower 层引用到最终的ASP.NET应用程序中，这是配置DI容器的位置。部署时，所有程序集都必须位于bin文件夹中，否则您的应用程序将无法运行。

UI层（ASP.NET应用程序）不直接与数据库通信。如果你正确地抽象了你的服务，它会谈到服务抽象，它与存储库抽象相对应，这取决于你如何配置你的DI会话到数据存储。

Answer 2

对于结构图来连接依赖关系一直到链，它将需要访问你实际将要使用的所有程序集。

这并不意味着UI必须引用那些（尽管这可能是最简单的解决方案）

你可以让你的UI引用程序集只包含它需要的接口，而不知道那些intferaces的实现（或者它们有什么依赖）

这意味着您的UI应该只知道您的服务层接口。

但是为了使应用程序能够将所有各个部分组合在一起，它必须知道要使用哪个服务实现，并且必须知道实现需要使用的任何依赖项的哪个实现，等等在所有的路上。这应该都在一个地方完成（我认为在ASP MVC应用程序中是global.ashx），这是对容器或其他实现类的任何引用应该存在的唯一地方。

您应用程序是所有层级的组合。它不是你的UI。

如果您根本不想引用这些程序集，那么您可以通过xml配置structuremap，然后可能会动态加载程序集。我不确定这一点，但我觉得应该有用。但是Xml配置比较麻烦。

只要您的服务接口注入UI控制器，那么您应该相当安全。对于某人使用其中一个引用的dll（如db层）的新依赖项，他们必须将该接口引入控制器并将其与结构图连接起来，这应该很容易发现。

Answer 3

去过那里。像你一样直接提出想法，认为避免汇编引用会解决所有问题。我甚至设法做了你正在尝试的后期构建xcopy'ing内置的dll`s。实际上 - 这只会让它变得比预想的更混乱。

事情是 - 引用本身不是邪恶的根源。 It's fine引用最上层（UI）程序集中的所有内容。糟糕的代码是造成麻烦的原因。