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

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

IQ>>имхо совершенно очевидно, что наивный сервис слепленный из хелперных методов DAL, ни в коем случае не является "абстракцией". Он предельно конкретный с предельно конкретными entity типами даже если структура этих типов продублирована, а данные копируются с помощью мапперов (эдакий карго-культ "абстрации"). Имхо здесь совершенно четко определяемая проблемы — интерфейсы верхних уровней начинают определять низкоуровневые интерфейсы DAL. Разрозненные хелперные методы не перестанут быть хелперными методами от того, что их вызывают через интерфейс.

V>И каким же образом он эту концепцию нарушает? BoringItemDataReader небось нужна какая-то конфигурация, ConnectionString, например, а то и IDbContext для стабильной работы, который обычно имеет свое время жизни и правила создания/освобождения и доступен как часть подсистемы, которая хранит настройки, т.е. отдельный сервис в вашей терминологии. Так же может легко еще зависеть от 2-3 абстракций, кэша например и т.д. Мне доводилось видеть поделки людей, которые считали, что для реализации инфраструктуры проекта хватит 10 классов хелперов и все будет ништяк, заканчивалось еще хуже, чем переусложенное новичками DI.

Хорошее дополнение. Я собственно написал пост только потому, что те, кто реализует "наивный DI" ничего вами перечисленного не создают и даже не собираются. Они тупо инжектируют аналоги статических классов со статическими хелперными методами.

Проблема которую я описываю в другом... в пропаганде в среде новичков идеи о том, что если к статическим методам статического класса приделать интерфейс и создавать через DI. То это уже нифига не code smell, а "хорошая архитектура".

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

V>И каким же образом он эту концепцию нарушает? BoringItemDataReader небось нужна какая-то конфигурация, ConnectionString, например, а то и IDbContext для стабильной работы, который обычно имеет свое время жизни и правила создания/освобождения и доступен как часть подсистемы, которая хранит настройки, т.е. отдельный сервис в вашей терминологии. Так же может легко еще зависеть от 2-3 абстракций, кэша например и т.д. Мне доводилось видеть поделки людей, которые считали, что для реализации инфраструктуры проекта хватит 10 классов хелперов и все будет ништяк, заканчивалось еще хуже, чем переусложенное новичками DI.

Хорошее дополнение. Я собственно написал пост только потому, что те, кто реализует "наивный DI" ничего вами перечисленного не создают и даже не собираются. Они тупо инжектируют аналоги статических классов со статическими хелперными методами.

Проблема которую я описываю в другом... в пропаганде в среде новичков идеи о том, что если к статическим методам статического класса приделать интерфейс и создавать через DI. То это уже нифига не code smell, а "хорошая архитектура".