Минулого року я створив нову систему, використовуючи Dependency Injection та контейнер IOC. Це мене багато чого навчило щодо DI!
Однак, навіть вивчивши поняття та правильні зразки, я вважаю викликом роз'єднати код та ввести контейнер IOC у застарілий додаток. Додаток є досить великим, щоб справжня реалізація була б величезною. Навіть якщо цінність була зрозуміла і час був наданий. Кому надано час на щось подібне ??
Мета звичайно - наблизити одиничні тести до бізнес-логіки!
Бізнес-логіка, що переплітається з тестовими викликами бази даних.
Я читав статті і розумію небезпеку ін'єкції залежності бідного чоловіка, як описано в цій статті Los Techies . Я розумію, це справді нічого не відриває.
Я розумію, що це може залучати багато системного рефакторингу, оскільки для реалізації потрібні нові залежності. Я б не розглядав можливість використовувати його в новому проекті з будь-якою величиною.
Запитання: Чи нормально використовувати DI Poor Man, щоб запровадити перевірку на застаріле додаток і розпочати прокатку кулі?
Окрім того, чи використання ІД бідного чоловіка як низового підходу до справжнього введення залежностей є цінним способом навчання необхідності та переваг цього принципу?
Чи можете ви рефакторувати метод, який має залежність від виклику бази даних та абстрактний, що викликає інтерфейс? Просто наявність цієї абстракції зробить те, що цей метод перевіряється, оскільки реалізація макету може бути передана через перевантаження конструктора.
Коли дороги наберуть прихильників, проект може бути оновлений для впровадження контейнера МОК, і там будуть конструктори, які беруть участь у абстракціях.
I consider it a challenge to decouple code and introduce an IOC container into a legacy application
звичайно, це так. Його називають технічним боргом. Ось чому перед будь-яким капітальним оновленням бажано малі та постійні рефактори. Зменшити основні вади дизайну і перехід до IoC було б менш складно.