为什么不使用IoC容器来解决实体/业务对象的依赖关系？

Question

为什么不使用IoC容器来解决实体/业务对象的依赖关系？

我理解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);
    }
}

如您所见，依赖项被注入构造函数。现在来问几个问题。

1. 让实体依赖外部类(如ShipQuunt)是否被认为是一种糟糕的做法？如果我正确地理解了这个定义，消除这些依赖似乎会导致我走向贫血的领域。

2. 使用IoC容器来解决这些依赖关系并在需要时构造一个实体是否是一种糟糕的做法？有可能这样做吗？

谢谢你的洞察力。