我理解DI背后的概念，但我只是学习不同的IoC容器可以做什么。看起来大多数人主张使用IoC容器来连接无状态服务，但是如何使用它们用于状态对象(如实体)呢？
无论是对还是错，我通常用我的实体行为，即使这种行为需要一个外部类。例：
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);
}
}
正如你可以看到的，依赖项是构造函数注入。现在有几个问题。
>将你的实体依赖于诸如ShipQuoter之类的外部类是不好的做法吗？如果我正确理解定义，消除这些依赖似乎导致我走向一个贫血的领域。
>使用IoC容器来解析这些依赖并在需要时构造实体是不是很糟糕的做法？有可能做到这一点吗？
感谢任何洞察。
第一个问题是最难回答的。实体是否依赖外部类是不好的做法吗？这当然不是最常见的事情。
原文链接：https://www.f2er.com/javaschema/282968.html例如，如果你注入一个Repository到你的Entities你有效地有一个实现的Active Record pattern.有些人喜欢这种模式为它提供了方便，而其他人(像我)认为它是一个代码气味或反模式，因为它违反Single Responsibility Principle(SRP)。
你可以说，注入其他依赖进入实体会拉你在同一个方向(远离SRP)。另一方面，你肯定是正确的，如果你不这样做，拉的是一个Anemic Domain Model。
我努力了所有这一切很长时间，直到我遇到Greg Young(放弃)paper on DDDD，在那里他解释为什么刻板的n层/ n层架构将永远是CRUDy(因此相当贫乏)。
将我们的焦点移动到将域对象建模为命令和事件而不是名词似乎使我们能够构建一个适当的面向对象的领域模型。
第二个问题更容易回答。您可以随时使用Abstract Factory to create instances at run-time.使用Castle Windsor，您甚至可以使用Typed工厂设施，减轻您手动实施工厂的负担。
