处理依赖注入——逻辑在哪里？
我正在开发一个 ASP.Net 网站以及用于我的业务逻辑、数据访问代码等的支持类库。
我对 Unity 框架和依赖注入作为一个整体非常陌生且不熟悉。不过，我通过遵循 codeplex 上 ASP.NET 3.5 Portal Starter Kit 的源代码，成功地使其正常工作。但这里存在问题：
类库是使用 Unity 设置的，并且我的几个类的属性具有 [Dependency] 属性（为此我专门使用属性设置器注入）。然而，Global.asax 告诉 Unity 如何处理类库中的注入......。
这是最佳实践还是类库应该处理它自己的注入，以便我可以在其他网站、网络应用程序或应用程序中重复使用该库？如果确实如此，那么在这种情况下注入代码会去哪里？
我不确定这个问题有多清楚。如果我需要解释更多，请告诉我。
I'm working on an ASP.Net website along with a supporting Class Library for my Business Logic, Data Access code, etc.
I'm EXTREMELY new and unfamiliar with the Unity Framework and Dependency Injection as a whole. However, I've managed to get it working by following the source code for the ASP.NET 3.5 Portal Starter Kit on codeplex. But herein lies the problem:
The Class Library is setup with Unity and several of my classes have [Dependency] attributes on their properties (I'm exclusively using property setter injections for this). However, the Global.asax is telling Unity how to handle the injections....in the Class Library.
Is this best practice or should the Class Library be handle it's own injections so that I can re-use the library with other websites, webapps or applications? If that is indeed the case, where would the injection code go in this instance?
I'm not sure how clear the question is. Please let me know if I need to explain more.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
尽管不熟悉 Unity（StructureMap 用户），但最终的映射应该存在于消费应用程序中。您可以让正在使用的 dll 定义这些映射，但您也希望能够在需要时覆盖它们。比如说，您需要一个 IFoo 实例，并且您在类库中映射了一个实例，但是您添加了一个新的实例来使用它，该实例仅存在于网站中。在站点中定义映射可以让您保持松散耦合，否则为什么要使用 DI 容器呢？
Though not familiar with Unity (StructureMap user) The final mappings should live in the consuming application. You can have the dll you are using define those mappings, but you also want to be able to override them when needed. Like say you need an instance of IFoo, and you have one mapped in your Class Library, but you've added a new one to use that just lives in the website. Having the mappings defined in the site allows you to keep things loosely coupled, or else why are you using a DI container?
就我个人而言，我尝试编写代码来促进 IOC 容器的发展，但绝不会尝试将 IOC 容器强制引入项目中。
我的解决方案大致如下：
（其中每一项都是项目）。
我尝试对项目引用保持严格的界限。实际的前端项目不能直接包含任何 *.Implementation 项目。 （在本例中，*.implementation 项目包含域中接口的实际实现）。因此 ASPNetMVCFrontEnd 引用了 Domain 和 DIInjectionWhatever 以及我的 DI 容器。
在 Project.DIInjectionWhatever 中，我将所有部分连接在一起。因此，该项目包含对实现和 DI 框架的所有参考。它包含注册组件的代码。 Autofac 让我可以轻松地分解组件注册，这就是我采用这种方法的原因。
在此示例中，我的实现项目中没有对容器的任何引用。这没有什么问题，如果您的实现需要它，那就继续吧。
Personally I try and code things to facilitate an IOC container but never will try and force an IOC container into a project.
My solution breakdown goes roughly:
(Each one of these are projects).
I try to maintain strict boundaries about projects references. The actual frontend project cannot contain any *.Implementation projects directly. (The *.implementation projects contain the actual implementations of the interfaces in domain in this case). So the ASPNetMVCFrontEnd has references to the Domain and the DIInjectionWhatever and to my DI container.
In the Project.DIInjectionWhatever I tie all the pieces together. So this project has all the references to the implementations and to the DI framework. It contains the code that does the registering of components. Autofac lets me breakdown component registration easily, so that's why I took this approach.
In the example here I don't have any references to the container in my implementation projects. There's nothing wrong with it, and if your implementation requires it, then go ahead.