Frontend -> Object Model / Business Logic -> Data Access
我一直在努力学习依赖注入,到目前为止已经发现它很棒(使用Autofac). 3层中的每一层都需要创建各种各样的对象,有时需要额外的配置/等.似乎DI容器应该是解决这个问题的理想选择,但是我遇到了一些问题,看看它应该与系统的其他部分相关.
目前我在前端有一个类来配置DI容器.它基本上是一大堆代码,说容器.Register< SomeType>()等等.
问题是,它正在为所有3层配置容器,因此必须具有对数据访问层的相当侵入性的知识.在我的前端有这样的知识的代码在我的头脑中引起了警钟,因为将应用程序分成层级的关键是避免这种情况.
由于我的数据访问层不仅仅是sql服务器是一个笨拙的桶,而是由许多复杂的COM互操作和P / Invoke调用组成,所以这也变得更糟,因此对DI有很大的影响组态.
我已经考虑过将其分解 – 可能每层有一个容器,或者每层都有一个“Setup”类与全局DI容器对话以注册它自己的位,但我不确定这是否会导致比它解决的问题更多……
如果有人可以分享他们使用DI与多层应用程序的经验,我将非常感激.
谢谢,猎户座.
另一方面,如果所有图层都在同一个进程中运行,那么您应该只有一个容器.容器将初始化并托管在应用程序的起始点,如web应用程序的global.asax.
容器主机知道系统的所有不同部分的问题可以通过不逐个注册类来解决,而是在程序集中注册所有类型.这样,只需配置容器,就不需要对解决方案中的所有程序集进行强引用.如何使用Castle Winsdor完成此操作:
Kernel.Register(AllTypes.Pick().FromAssemblyName("DataAccessLayer.dll")); Kernel.Register(AllTypes.Pick().FromAssemblyName("BusinessLogic.dll"));
原文地址:https://www.jb51.cc/javaschema/281482.html
版权声明:本文内容由互联网用户自发贡献,该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容, 请发送邮件至 dio@foxmail.com 举报,一经查实,本站将立刻删除。