使用unity将业务逻辑层与数据访问层解耦答案

【问题标题】：Using unity to decouple business logic layer from data access layer使用unity将业务逻辑层与数据访问层解耦
【发布时间】：2011-03-05 16:32:21
【问题描述】：

我已经在我的 Asp.Net MVC2 项目中实现了 Unity。我目前正在 Application Start 上注册我的 BLL 类型。

然后我创建了一个名为 UnityControllerFactory 的类，它负责解决我在控制器中的依赖关系。我只是通过使用依赖属性来使用属性注入来完成此操作。

我的下一个想法是删除我的 BLL 类中包含的依赖项，这些依赖项与 DAL 层类的具体实现相关联。我还希望能够通过属性注入而不是构造函数注入来做到这一点，因为我在 Bll 类方法中引用了多个类。

我希望对解决这个确切问题的任何解决方案提供一些指导，还是这完全是矫枉过正？

【问题讨论】：

标签： asp.net-mvc-2 data-access-layer business-logic

【解决方案1】：

如果您的 BLL 类是由 Unity 创建的，那么这不会成为问题，容器只会在创建 BLL 类时提供所需的依赖项。如果不是，那么您将遇到问题，因为一般来说，创建 BLL 类的对象也应该提供它的依赖项。

不过，我想提醒您注意使用基于属性的注入。依赖注入世界中的一般经验法则是 required 依赖项应该通过构造函数注入，而 optional 依赖项应该通过属性注入。如果您的类需要另一个类来完成它的工作，那么不应该有任何方法来创建该类的实例而没有它所需的依赖项。

您提到使用属性注入是因为您的 BLL 类中存在大量依赖项。虽然我理解这一点，但我认为遵循 required = 构造函数规则仍然至关重要。如果您最终得到一个具有太多依赖项的构造函数，那么这是一种代码异味，它指向您设计中某个地方的问题。可能是该类承担了太多责任（如果您发现某些方法需要一组依赖项，而另一组需要一组不同的依赖项，通常会出现这种情况）。也可能是对依赖项所做的工作过于细化，并且可能被包装在另一个可以协调依赖类工作的对象中。

【讨论】：

我相信是后者，我可能使我的业务逻辑层类过于细化。我将研究重构我的业务逻辑层类以封装一些相关的业务实体功能。问题是我的领域模型很大，还有很多不相关的对象。我仍然很好奇是否有任何好的文章，其中提供了一些关于如何创建要在应用程序的不同层中使用的容器的指导？
在听取您的建议后，将我的业务逻辑层类重构为分组功能。我已经简化了依赖项，并为我的每个控制器和 BLL 类实现了一个构造函数，它们的依赖项由 Unity 注入。我非常感谢您的帮助和指导。
很高兴我能提供帮助，特别是如果它帮助您找到更简单的解决方案。