Пусть начальство решает по тестерам, а ведущий программист по тому, будут модульные тесты или нет, исходя из поставленных задач.
Скажем, алгоритм быстрой сортировки быстрее и правильнее проверить тестом, нежели отладочным консольным приложением или, что ещё хуже, в реальном приложении (убедиться, что всё будет хорошо в программе, стоит конечно, но не отлаживать таким образом).
Определите, как минимум:
1) кто отвечает за трансляцию из одной модели в другую. Пусть эта сущность больше ничем не занимается, тогда у неё будет своё имя, а helper'ы больше не будут вызывать вопросов.
2) кто отвечает за работу с DataContext и как он это будет делать
2.1) будет ли он получать фильтр для данных (пользователей) извне или сам будет строить Expression<Func<T, bool>>
2.2) в каком виде он будет возвращать данные — готовые коллекции/списки или IQueryable
По примерам кода можно предположить, что нету стремления получать именно перечисления в GetUsers, но есть желание получать фильтрованный список пользователей. Тогда IEnumerable вычёркиваем.
IQueryable тоже вычёркиваем — извне не используете, тогда зачем его возвращать? Возвращайте готовую коллекцию/список.
Лишнее наследование UserRepository: MyProjectDataContext можно заменить разделением ответственностей по классам либо создав нужные методы DataContext'а в partial классе.
Если он действительно просто позволит записывать в БД все unhandled exceptions, то тогда надо пробовать!
Насколько это дополнительно нагрузит сайт, если посетителей много и исключения пока, к сожалению, не редкость (есть опыт?). Особенно, если по каждой ошибке надо будет писать в БД (удалённую), отсылать по e-mail.
На лету можно. Достаточно создать свой MarkupExtension, в котором подписываться на изменения культуры. При этом перегружать значения ресурс файлов. «WPF Localization on-the-fly».
Так, а как на счёт runtime? В wpf можно с помощью markupextentions сделать именно решение, которое бы «на лету» обновляло бы весь интерфейс при смене культуры.
К проблемам ещё и то, что он процессор «кушает» циклом. Так что резонно задуматься всё же в сторону сторонних choice & sleep, с помощью которых delay делается на ура.
Скажем, алгоритм быстрой сортировки быстрее и правильнее проверить тестом, нежели отладочным консольным приложением или, что ещё хуже, в реальном приложении (убедиться, что всё будет хорошо в программе, стоит конечно, но не отлаживать таким образом).
Cтажёр и младший программист с радостью начинают писать юнит тесты, чтобы понять, что такое хороший дизайн (сразу заметен «рост»).
Бывалый программист говорит, что и так всё знает («лень») и спихивает всё на тестеров (сразу заметно, кто плодит больше багов и отлаживает по F5).
Eсли команда примет решение (писать тесты), отговорки должны быть неуместны имхо.
Определите, как минимум:
1) кто отвечает за трансляцию из одной модели в другую. Пусть эта сущность больше ничем не занимается, тогда у неё будет своё имя, а helper'ы больше не будут вызывать вопросов.
2) кто отвечает за работу с DataContext и как он это будет делать
2.1) будет ли он получать фильтр для данных (пользователей) извне или сам будет строить Expression<Func<T, bool>>
2.2) в каком виде он будет возвращать данные — готовые коллекции/списки или IQueryable
По примерам кода можно предположить, что нету стремления получать именно перечисления в GetUsers, но есть желание получать фильтрованный список пользователей. Тогда IEnumerable вычёркиваем.
IQueryable тоже вычёркиваем — извне не используете, тогда зачем его возвращать? Возвращайте готовую коллекцию/список.
Лишнее наследование UserRepository: MyProjectDataContext можно заменить разделением ответственностей по классам либо создав нужные методы DataContext'а в partial классе.
Попадаю в ~13% «От часа до полутора часов» (на машине) — сильная процентовка. Думал, что это актуально для большинства, пора что-то менять.
Насколько это дополнительно нагрузит сайт, если посетителей много и исключения пока, к сожалению, не редкость (есть опыт?). Особенно, если по каждой ошибке надо будет писать в БД (удалённую), отсылать по e-mail.
К сожалению, не помню ссылку на оригинальный источник