Чому б не використовувати контейнер 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 для вирішення цих залежностей та побудови сутності за потреби? Чи можна це зробити?

Дякуємо за будь-яке розуміння.

На перше питання відповісти найважче. Чи погана практика, коли організації залежать від зовнішніх класів? Це, звичайно, не найпоширеніша справа.

Наприклад, якщо ви вводите сховище у свої сутності, ви фактично маєте реалізацію шаблону Active Record . Деяким людям цей шаблон подобається для зручності, який він надає, тоді як інші (як я) вважають його запахом коду або анти-шаблоном, оскільки він порушує Принцип єдиної відповідальності (SRP).

Ви можете стверджувати, що ін'єкція інших залежностей в сутності призведе до того, що ви в тому ж напрямку (подалі від SRP). З іншого боку, ви, безумовно, праві, що якщо ви цього не зробите, тяга буде спрямована на Анемічну модель домену .

Я боровся з усім цим протягом тривалого часу, поки не натрапив на документ Грега Янга (відмовився) про DDDD, де він пояснює, чому стереотипна архітектура n-рівня / n-шару завжди буде CRUDy (і, отже, досить анемічна ).

Переміщення нашого фокусу на моделюванні об’єктів домену як команд та подій замість іменників, схоже, дозволяє нам створити належну об’єктно-орієнтовану модель домену.

На друге питання легше відповісти. Ви завжди можете використовувати абстрактну фабрику для створення екземплярів під час виконання . За допомогою Castle Windsor ви навіть можете скористатися Typed Factory Facility, позбавляючи вас від тягаря впровадження заводів вручну.

Я знаю, що це стара публікація, але хотів додати. Сутність домену не повинна зберігатися, навіть якщо ви переходите до абстрактного сховища в ctor. Причина, по якій я пропоную це, полягає не просто в тому, що він порушує SRP, а також суперечить агрегації DDD. Дозвольте мені пояснити, DDD підходить для складних додатків із глибинними по своїй суті графіками, тому ми використовуємо агреговані або складені корені, щоб продовжувати змінювати основні "діти", тому, коли ми вводимо наполегливість у окремих дітей, ми порушуємо відносини дітей до складений або сукупний корінь, який повинен «керувати» життєвим циклом або агрегацією. Звичайно, складений корінь або сукупність також не зберігаються на власному графіку. Інша ситуація з ін’єкційними залежностями об’єктів DDD полягає в тому, що ін’єктований об’єкт домену фактично не має стану, поки не відбудеться якась інша подія для гідратації його стану. Будь-який споживач коду буде змушений спершу ініціювати або налаштувати об’єкт домену, перш ніж він зможе викликати ділову поведінку, яка порушує інкапсуляцію.