Сообщение Re[16]: О пользе Dependency Injection от 19.01.2021 4:17
Изменено 19.01.2021 5:30 Министр Промышленности из Minecraft'а
Re[16]: О пользе Dependency Injection
МП>>ойойой
МП>>а как же интересно вели командную разработку году так в 2005, когда DI извращения ещё не придумали?
AA>Как бы это лучше сказать? Через одно место вели.
нет, вели приемлемо
а если лид хоть как-то продумывал вопросы параллельной разработки — так и вообще без проблем
например делали временную реализацию того же интерфеса, все методы которой вначале кидают NotImplementedException
AA>Втоорй профит кстати в том, что клиентский модуль будет работать без перекомпиляции если пришлось пофиксить реализацию.
тут уже разобрали этот фактор в обсуждении
когда это реально нужно — принимается как некоторый аргумент "за", хотя и привносит свои риски и затруднения
AA>В случае же с явным созданием зависимого объекта через конструктор придется что? ребилдить весь солюшн.
AA>Ай-йа-яй!
ребилдить весь солюшен — это чистое и довольно хорошее решение
кроме случаев когда ребилд занимает слишком много времени — сутки, несколько часов
в описанном вами случае ребилдить придётся только клиентский модуль с его зависимостями
AA>И кстати. нечего не явного не вижу в DI.
AA>
AA>Зато точка сборки приложения одна а не размазана по разным сборкам.
ну неет
МП>>а как же интересно вели командную разработку году так в 2005, когда DI извращения ещё не придумали?
AA>Как бы это лучше сказать? Через одно место вели.
нет, вели приемлемо
а если лид хоть как-то продумывал вопросы параллельной разработки — так и вообще без проблем
например делали временную реализацию того же интерфеса, все методы которой вначале кидают NotImplementedException
AA>Втоорй профит кстати в том, что клиентский модуль будет работать без перекомпиляции если пришлось пофиксить реализацию.
тут уже разобрали этот фактор в обсуждении
когда это реально нужно — принимается как некоторый аргумент "за", хотя и привносит свои риски и затруднения
AA>В случае же с явным созданием зависимого объекта через конструктор придется что? ребилдить весь солюшн.
AA>Ай-йа-яй!
ребилдить весь солюшен — это чистое и довольно хорошее решение
кроме случаев когда ребилд занимает слишком много времени — сутки, несколько часов
в описанном вами случае ребилдить придётся только клиентский модуль с его зависимостями
AA>И кстати. нечего не явного не вижу в DI.
AA>
AA> services.AddSingleton<IMainService, MainService>(); // Что тут неявного?
AA> services.AddHostedService(prop => prop.GetService<IMainService>() as MainService); // Что тут неявного?
AA> services.AddDbContext<DbContext>(options =>
AA> options.UseSqlServer(
AA> Configuration.GetConnectionString("DefaultConnection"))); // Что тут неявного?
AA>AA>Зато точка сборки приложения одна а не размазана по разным сборкам.
ну неет
Re[16]: О пользе Dependency Injection
МП>>ойойой
МП>>а как же интересно вели командную разработку году так в 2005, когда DI извращения ещё не придумали?
AA>Как бы это лучше сказать? Через одно место вели.
нет, вели приемлемо
а если лид хоть как-то продумывал вопросы параллельной разработки — так и вообще без проблем
например делали временную реализацию того же интерфеса, все методы которой вначале кидают NotImplementedException
AA>Втоорй профит кстати в том, что клиентский модуль будет работать без перекомпиляции если пришлось пофиксить реализацию.
тут уже разобрали этот фактор в обсуждении
когда это реально нужно — принимается как некоторый аргумент "за", хотя и привносит свои риски и затруднения
AA>В случае же с явным созданием зависимого объекта через конструктор придется что? ребилдить весь солюшн.
AA>Ай-йа-яй!
ребилдить весь солюшен — это чистое и довольно хорошее решение
кроме случаев когда ребилд занимает слишком много времени — сутки, несколько часов
в описанном вами случае ребилдить придётся только клиентский модуль с его зависимостями
AA>И кстати. нечего не явного не вижу в DI.
AA>
AA>Зато точка сборки приложения одна а не размазана по разным сборкам.
ну неет
точка сборки приложения действительно лучше бы была одна, а именно — в .sln файле
попытка придать зависимостям характер аспекта явно натянута
нет такой проблемы чтобы вот так вот пахабить код вместо естественной инициализации
и код это не сокращает
и вынос всех конструирований зависимостей в одно место сходно с плохим примером объединения классов по сборкам,
ну не по алфавитному порядку их названий конечно
по принципу: классы, которые имеют параметризованные конструкторы инициализируем не где это надо, а вот здесь!
а с классами, которые скажем имеют события или подтипы — вы ничего не хотите сделать?
МП>>а как же интересно вели командную разработку году так в 2005, когда DI извращения ещё не придумали?
AA>Как бы это лучше сказать? Через одно место вели.
нет, вели приемлемо
а если лид хоть как-то продумывал вопросы параллельной разработки — так и вообще без проблем
например делали временную реализацию того же интерфеса, все методы которой вначале кидают NotImplementedException
AA>Втоорй профит кстати в том, что клиентский модуль будет работать без перекомпиляции если пришлось пофиксить реализацию.
тут уже разобрали этот фактор в обсуждении
когда это реально нужно — принимается как некоторый аргумент "за", хотя и привносит свои риски и затруднения
AA>В случае же с явным созданием зависимого объекта через конструктор придется что? ребилдить весь солюшн.
AA>Ай-йа-яй!
ребилдить весь солюшен — это чистое и довольно хорошее решение
кроме случаев когда ребилд занимает слишком много времени — сутки, несколько часов
в описанном вами случае ребилдить придётся только клиентский модуль с его зависимостями
AA>И кстати. нечего не явного не вижу в DI.
AA>
AA> services.AddSingleton<IMainService, MainService>(); // Что тут неявного?
AA> services.AddHostedService(prop => prop.GetService<IMainService>() as MainService); // Что тут неявного?
AA> services.AddDbContext<DbContext>(options =>
AA> options.UseSqlServer(
AA> Configuration.GetConnectionString("DefaultConnection"))); // Что тут неявного?
AA>AA>Зато точка сборки приложения одна а не размазана по разным сборкам.
ну неет
точка сборки приложения действительно лучше бы была одна, а именно — в .sln файле
попытка придать зависимостям характер аспекта явно натянута
нет такой проблемы чтобы вот так вот пахабить код вместо естественной инициализации
и код это не сокращает
и вынос всех конструирований зависимостей в одно место сходно с плохим примером объединения классов по сборкам,
ну не по алфавитному порядку их названий конечно
по принципу: классы, которые имеют параметризованные конструкторы инициализируем не где это надо, а вот здесь!
а с классами, которые скажем имеют события или подтипы — вы ничего не хотите сделать?