Re[19]: О "наивном" DI и об архитектурном бессилии
От: IQuerist Мухосранск  
Дата: 26.09.16 14:46
Оценка:
Здравствуйте, ·, Вы писали:

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



IQ>>Что за ужосы??? Какие камменты? ServiceLocator.GetCurrentUserInfo

·>Я вот тут хорошее объяснение окнопал на пальцах и с картинками почему этот твой подход говно:
·>http://blog.ploeh.dk/2010/02/03/ServiceLocatorisanAnti-Pattern/
·>Ну и вывод совпадающий с моим:

The compiler can offer both consumers and producers so much help when Constructor Injection is used, but none of that assistance is available for APIs that rely on Service Locator.


·>Собственно, прежде чем отвечать на предыдущий пост ознакомься с этой статьёй и пиши возражения по делу, если есть.


Нда... Как говорит народная мудрость лучше всего бандиты решают те проблемы которые сами и создают В посте Seemann создал инвалидное решение, огреб проблем и доблестно все порешал с помощью constructor injection! Какую же проблему он решил? А оказывается OrderProcessor.Process(Order order) внутри использует IOrderValidator! Но зачем явно передавать его в конкретный метод, если можно где-то там, за ширмой неявно затаскивать его через конструктор в DI? Ведь достаточно будет посмотреть конструктор, и метод инициализации всех сервисов системы и все сразу станет понятно! Не забывайте это делать при вызове каждого метода сервиса и пожалуйста отслеживайте все время изменения, которые вносят ваши коллеги. Кроме валидатора, в OrderProcessor.Process можно затащить много любопытных вещей, а вы, по api об этом даже не узнаете Это очень удобно.
 
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.