Сообщение Re[16]: О пользе Dependency Injection от 19.01.2021 4:17
Изменено 19.01.2021 4:21 Министр Промышленности из Minecraft'а
Re[16]: О пользе Dependency Injection
МП>>ойойой
МП>>а как же интересно вели командную разработку году так в 2005, когда DI извращения ещё не придумали?
AA>Как бы это лучше сказать? Через одно место вели.
нет, вели приемлемо
а если лид хоть как-то продумывал вопросы параллельной разработки — так и вообще без проблем
AA>Втоорй профит кстати в том, что клиентский модуль будет работать без перекомпиляции если пришлось пофиксить реализацию.
тут уже разобрали этот фактор в обсуждении
когда это реально нужно — принимается как некоторый аргумент "за", хотя и привносит свои риски и затруднения
AA>В случае же с явным созданием зависимого объекта через конструктор придется что? ребилдить весь солюшн.
AA>Ай-йа-яй!
ребилдить весь солюшен — это чистое и довольно хорошее решение
кроме случаев когда ребилд занимает слишком много времени — сутки, несколько часов
в описанном вами случае ребилдить придётся только клиентский модуль с его зависимостями
AA>И кстати. нечего не явного не вижу в DI.
AA>
AA>Зато точка сборки приложения одна а не размазана по разным сборкам.
ну неет
МП>>а как же интересно вели командную разработку году так в 2005, когда DI извращения ещё не придумали?
AA>Как бы это лучше сказать? Через одно место вели.
нет, вели приемлемо
а если лид хоть как-то продумывал вопросы параллельной разработки — так и вообще без проблем
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>Зато точка сборки приложения одна а не размазана по разным сборкам.
ну неет
МП>>а как же интересно вели командную разработку году так в 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>Зато точка сборки приложения одна а не размазана по разным сборкам.
ну неет