问题描述
我了解 DI 背后的概念，但我只是在学习不同的 IoC 容器可以做什么.似乎大多数人都提倡使用 IoC 容器来连接无状态服务，但是将它们用于像实体这样的有状态对象呢?
I understand the concept behind DI, but I'm just learning what different IoC containers can do. It seems that most people advocate using IoC containers to wire up stateless services, but what about using them for stateful objects like entities?
无论是对还是错，我通常用行为填充我的实体，即使该行为需要外部类.示例:
Whether it's right or wrong, I normally stuff my entities with behavior, even if that behavior requires an outside class. Example:
public class Order : IOrder
{
private string _ShipAddress;
private IShipQuoter _ShipQuoter;
public Order(IOrderData OrderData, IShipQuoter ShipQuoter)
{
// OrderData comes from a repository and has the data needed
// to construct order
_ShipAddress = OrderData.ShipAddress; // etc.
_ShipQuoter = ShipQuoter;
}
private decimal GetShippingRate()
{
return _ShipQuoter.GetRate(this);
}
}
如您所见，依赖项是构造函数注入的.现在有几个问题.
As you can see, the dependencies are Constructor Injected. Now for a couple of questions.
让您的实体依赖于诸如 ShipQuoter 之类的外部类是否被认为是不好的做法?如果我正确理解了定义，那么消除这些依赖性似乎会将我引向一个贫乏的领域.
Is it considered bad practice to have your entities depend on outside classes such as the ShipQuoter? Eliminating these dependencies seems to lead me towards an anemic domain, if I understand the definition correctly.
使用 IoC 容器来解决这些依赖关系并在需要时构造一个实体是一种不好的做法吗?可以这样做吗?
Is it bad practice to use an IoC container to resolve these dependencies and construct an entity when needed? Is it possible to do this?
感谢您的任何见解.
推荐答案
第一个问题是最难回答的.让实体依赖于外部类是不好的做法吗?这当然不是最常见的做法.
The first question is the most difficult to answer. Is it bad practice to have Entities depend on outside classes? It's certainly not the most common thing to do.
例如，如果您将 Repository 注入到您的实体中，您实际上已经实现了 Active Record 模式.有些人喜欢这种模式是因为它提供了便利，而其他人(比如我)认为它是一种代码异味或反模式，因为它违反了 单一职责原则 (SRP).
If, for example, you inject a Repository into your Entities you effectively have an implementation of the Active Record pattern. Some people like this pattern for the convenience it provides, while others (like me) consider it a code smell or anti-pattern because it violates the Single Responsibility Principle (SRP).
您可能会争辩说，将其他依赖项注入实体会将您拉向同一方向(远离 SRP).另一方面，你当然是正确的，如果你不这样做，拉动是朝着 贫血域模型.
You could argue that injecting other dependencies into Entities would pull you in the same direction (away from SRP). On the other hand you are certainly correct that if you don't do this, the pull is towards an Anemic Domain Model.
我在这一切中挣扎了很长时间，直到我遇到了 Greg Young(被遗弃)关于 DDDD 的论文，他解释了为什么陈规定型的 n 层/n 层架构将始终是 CRUDy(因此相当贫乏).
I struggled with all of this for a long time until I came across Greg Young's (abandonded) paper on DDDD where he explains why the stereotypical n-tier/n-layer architecture will always be CRUDy (and thus rather anemic).
将我们的注意力转移到将领域对象建模为命令和事件而不是名词似乎使我们能够构建一个适当的面向对象的领域模型.
Moving our focus to modeling Domain objects as Commands and Events instead of Nouns seems to enable us to build a proper object-oriented domain model.
第二个问题更容易回答.您始终可以使用抽象工厂在运行时创建实例.借助 Castle Windsor，您甚至可以使用 Typed Factory Facility，从而减轻您手动实施工厂的负担.
The second question is easier to answer. You can always use an Abstract Factory to create instances at run-time. With Castle Windsor you can even use the Typed Factory Facility, relieving you of the burden of implementing the factories manually.
这篇关于为什么不使用 IoC 容器来解决实体/业务对象的依赖关系?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！