Здравствуйте, Ночной Смотрящий, Вы писали:

НС>Здравствуйте, varenikAA, Вы писали:

AA>>Однозначно нужны. Как только ты начинаешь писать реальное ПО, то сразу понимаешь всю прелесть.

НС>И в чем она?

Ну хотя бы в том, что автоматически следит за скоупом.
При работе с БД это очень важно. Грабли могут вылезти внезапно.

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

НС>>И в чем она?
AA>Ну хотя бы в том, что автоматически следит за скоупом.
AA>При работе с БД это очень важно. Грабли могут вылезти внезапно.

При работе с БД это совершенно неважно, потому что коннект к БД ни в коем случае не должен находится в скоупе.

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

MH>но зачем?
MH>для тестов? на моем опыте, можно делать где-то глобальный флаг типа TestMode, и сервис типа EmailSender в тестовом режиме
MH>просто ничего реально не посылает, ну или как-то иначе нужным образом изменяет поведение для тестов.
MH>1-й вариант и проще (нет кучи лишних сущностей, заморачивания с их моками/инстанцированием и тп), и потребности тестирования покрывает..

TestMode как правило не нужен. Для EmailSender, что нужен лишь настраиваемый в конфиге "результат действия" — штатная отправка письма, сохранение в pickup директорию (отправка не происходит), "перенаправление" т.е. очистка to, cc, bcc и отправка на спец. ящик или вызов внешнего метода куда отдается финальный email. И никаких IEmailSender.

Если моками не занимается отдельная команда, цель которой регулярно, тотально и брутально обрушивать ваш домен, то моки — карго культ, литании дядюшке Бобу.

Вклад DI framework в современную разработку огромен, если вы видите реализацию где всю логику вынесли нафиг в stored proc и client javascript, в серверном бизнес слое ошметки с вкраплениями IUserProvider, ILogProvider, IEmailProvider, IDbStoreProvider, IIntegrationProvider и все это связано json rest протоколом то это тот самый loose coupled design! Домен полностью дезинтегрирован и ничто не ограничивает в том, чтобы творить любую с т.з. бизнеса дичь.