2011-06-27 52 views
2

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

我的UI层应该只知道服务层。我的UI不应该知道或关心业务,更不用说存储库或数据层。每一层是它自己的程序集,我使用构造函数依赖注入来注入必要的实例(即,我将业务对象注入到我的服务构造函数中,并将存储库对象注入到业务构造函数中)。因此,如果我的层位于单独的程序集中,并且结构图所在的UI组件不知道下层,那么如何配置结构图?我不愿意在我的UI层中创建所有位于服务层后面的“较低”层的引用。如果我这样做,那么这可能会为UI直接与数据库进行交谈打开大门,这是不好的。

请帮忙。

感谢

汤姆

+0

你试过了吗?我相信它会扫描整个应用程序域,其中应包括所有程序集。我可能是错的,虽然;) –

+0

@RexM你没有错。如果可以找到它们,StructureMap确实可以连接所有组件。 –

回答

2

在那里做过。直接就像你一样的想法,认为避免汇编引用将解决一切。我甚至成功地做了你正在试图用后构建xcopy'ing构建的DLL。事实上 - 这只是让它变得比它应该的更混乱。

事情是 - 引用本身并不是邪恶根源。 It's fine以引用来自最上面的(UI)程序集的所有内容。不好的代码是造成麻烦的原因。

2

我不愿意建立在我的UI层对这些坐在服务层后面的所有“低”层次的引用。如果我这样做,那么这可能会为UI直接与数据库进行交谈打开大门,这是不好的。

你应该引用所有层到最终ASP.NET应用程序,它是在DI容器被配置在哪里。部署时,所有程序集都必须位于bin文件夹中,否则您的应用程序将无法工作。

UI层(ASP.NET应用程序)不直接与数据库交谈。如果你正确地抽象了你的服务,那么它就会与服务抽象进行对话,这个服务抽象根据存储库抽象进行协商,这取决于你如何配置你的DI对话到数据存储。

2

对于结构图来连接链中的依赖关系,它将需要访问您实际要使用的所有程序集。

这并不意味着用户界面必须引用那些虽然(尽管这可能是最简单的解决方案)

你可以让你只包含它所需要的接口,在不知道任何UI组件参考这些intferaces的实现(或他们有什么依赖关系)

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

要不是你应用能够使用所有的各个部分共同它必须知道要使用的服务实现的,必须知道哪些实现,它的实现需要使用任何依赖关系,等等一路下线。这应该全部在一个地方完成(global.ashx在我认为的ASP MVC应用程序中),并且这是对容器或其他实现类的任何引用都应该存在的唯一位置。

应用程序是所有层级的组合。这不仅仅是你的用户界面。

如果你不想引用那些程序集,那么你可以通过xml来配置结构图,这可能会动态加载程序集。我对此不确定,但我认为它应该起作用。但Xml配置更麻烦。

只要你的服务接口注入你的UI控制器,那么你应该是相当安全的。对于某些人使用像db层这样的引用dll中的一个新的依赖关系,他们必须将该接口引入控制器并将其与结构图连接起来,这应该很容易被发现。