Здравствуйте, ·, Вы писали:

V>>>>Специально попытался найти официальное определение — не нашёл.
V>>·>Это понятие родилось где-то в Spring, стоит читать его доку.
V>>Читал. Именно определения не нашёл.
·>Ну потому что официального особо ничего нет... Но это вроде терпимо как некое описание:
·>IoC creates the objects, configures and assembles their dependencies, manages their entire life cycle. The Container uses Dependency Injection to manage the components that make up the application.
Это только описание конкретной реализации. А общего термина с определением, похоже. нет

·>Поэтому я и пытаюсь повернуть разговор в русло "а как же делать хорошо?". Так вот фреймворк сделать хорошо — не позволяет, принципиально. Хорошо можно делать wiring-кодом.
Я бы сказал, фреймворк не позволяет делать так, как хочется (потому он, собственно, и фреймворк).
Делать приемлемо (путсь не хорошо) фреймворк позволяет.


V>>·>Сложная инициализация wiring-кодом пишется и тестируется гораздо проще, чем на фреймворке. Но, повторюсь, на wiring код можно хотя бы натравить инструменты и найти ошибки-варнинги. С фреймворком будет говно и никак ни проанализировать, ни исправить, единственный надёжный тест — запустить на проде и поглядеть что поломалось.
V>>К сожалению, инициализация в тестовом режиме не проверит инициализацию в проде. Просто потом, что это другая инициализация.
·>Примерно то же самое можно сказать о любом коде "обработка данных в тестовом режиме не проверит обработку данных в проде. Просто потому, что это другие данные". Но ведь более менее работающий код таки умудряются иногда писать.

·>Так вот, инициализация это такой же код как и всё остальное. Раз умеешь качественно писать на ЯП код бизнес-логики, то в чём проблема писать код инициализации — не понимаю.

V>>>>>>Чтобы написать — не нужен. А чтобы хранить ссылку на эту фабрику для её использования из разных мест нужен либо библиотечный контейнер либо самописный.
V>>·>Чё? wiring-код ничего не вызывает, кроме конструкторов (ну ладно, ещё может билдеры сложных компонент). Вызовы логики происходят внутри связываемых компонент и ни в wiring-коде, ни в конфиге фреймворка их быть не должно. Т.е. в wiring-коде эту фабрику не надо использовать — её надо только создать и передать конструкторам других компонент.
V>>ок, скажу совсем просто: нужно передать фабрику в 2 конструктора. Для этого её нужно сохранить в переменной, так ведь? Эта переменная и будет точкой хранения.
·>Т.е. если тебе значение sin(x) нужно передать в две функции, то его нужно сохранить в переменной. Значит нужен библиотечный или самописный контейнер для хранения sin(x)??!
·>Пойми простую мысль:
·>

·>var y = sin(x);
·>var a = f1(y);
·>var b = f2(y);
·>

·>и
·>

·>var factory = new RequestContextFactory(db);
·>var thing1 = new Thing1(factory);
·>var thing2 = new Thing2(factory);
·>

·>Отличается только именами символов.
Именно! И вот в этом случае переменная y (или factory) и будет той самой переменной, о которой я говорю.
Это и будет примитивный IoC контейнер, в данном простейшем случае — из одной переменной.


V>>Второй стиль (готовая библиотека)
·>

V>>var db = myServices.Get<IDatabase>();
·>

·>Это и есть антипаттерн SL. Так не надо делать. Это противоположность DI.
У MS такой вариант как раз и называется Dependency Injection

V>>>>Это не важно, я про фреймворк. Если он внутри использует DI контейнер, то довольно сложно избежать его использования.
V>>·>Я не знаю что такое DI-контейнер. На всякий случай: "dependency injection is a programming technique in which an object or function receives other objects or functions that it requires, as opposed to creating them internally"
V>>Имелся в виду IoC контейнер. Я иногда ошибочно пишу DI контейнер
·>Значит я не понял твою мысль здесь...
Да мысль простая. Если пишете, например, ASP.NET приложение, которое в своей основе имеет IoC контейнер с сервисами, то не использовать его не получится.