Почему бы не использовать контейнер 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. Считается ли плохой практикой, чтобы ваши объекты зависели от внешних классов, таких как ShipQuoter? Устранение этих зависимостей, кажется, ведет меня к анемичной области, если я правильно понимаю определение.

2. Является ли плохой практикой использование контейнера IoC для разрешения этих зависимостей и создания объекта, когда это необходимо? Возможно ли это сделать?

Спасибо за любую информацию.