Почему не стоит использовать явно в бизнес-логике конкретную технологию доступа к данным?
Во-первых, можно создать другую реализацию IRepository и работать с другим источником. Достаточно будет реализовать репозитории, не потребуется переписывать весь код, который использовал DBContext. Скрее всего достаточно будет поправить 2 класса — RepositoryBase и RepositoryContext.
Во-вторых (сводится к п.1), можно легко замокать репозиторий и написать юнит-тест на бизнес-логику.
В-третьих, простота расширения. Из реализации на GitHub я удалил часть интерфейса IRepository, связанного с использованием автомаппинга и извлечения недоменных объектов, связанных через AutoMapper с Entity, но достаточно добавить этот код в одном месте и он станет доступен для всех сущностей.
Я согласен, что репозиторий сам по себе является спорным шаблоном, есть UoF и CQRS, но статья немного о другом.
Возможно, я слишком увлёкся технической составляющей.
Уход от явного использования DBContext, который используется только в регистрации.
CRUD над источником данных, сразу зарегистрированный в контейнере для любой сущности, реализующей определенный интерфейс.
Возможность строить нетривиальные запросы к репозиторию, которые транслируются в IQueryable.
И всё это без написания кода самих репозиториев: generic даёт достаточно функциональности.
Очень удобно для новых и особенно некрупных (до 100.000 строк) проектов, когда модель данных меняется в процессе уточнений — можно написать POCO-объект и к нему сразу появится готовый репозиторий в контейнере. Пишите только бизнес-логику, не инфраструктуру.
Да, я не указал, что звезды это еще и дешевый (бесплатный?) KPI, но на сколько он репрезентативен и стоит ли вообще при работе с программистами использовать показатели эффективности — вопрос отдельный и спорный. Любой KPI можно накрутить искусственно, есть даже личности, которые принципиально могут собирать звезды и не тратить их. В случае с нематериальными бонусами это будет эквивалентно выводу звезд из обращения и будет сдерживать инфляцию, а если начинать раздавать материальные плюшки, то может быть всякое. Не думаю, что дойдёт до продажи звезд за деньги, но мы не рисковали вводить такую систему.
Во-первых, можно создать другую реализацию IRepository и работать с другим источником. Достаточно будет реализовать репозитории, не потребуется переписывать весь код, который использовал DBContext. Скрее всего достаточно будет поправить 2 класса — RepositoryBase и RepositoryContext.
Во-вторых (сводится к п.1), можно легко замокать репозиторий и написать юнит-тест на бизнес-логику.
В-третьих, простота расширения. Из реализации на GitHub я удалил часть интерфейса IRepository, связанного с использованием автомаппинга и извлечения недоменных объектов, связанных через AutoMapper с Entity, но достаточно добавить этот код в одном месте и он станет доступен для всех сущностей.
Я согласен, что репозиторий сам по себе является спорным шаблоном, есть UoF и CQRS, но статья немного о другом.
Очень удобно для новых и особенно некрупных (до 100.000 строк) проектов, когда модель данных меняется в процессе уточнений — можно написать POCO-объект и к нему сразу появится готовый репозиторий в контейнере. Пишите только бизнес-логику, не инфраструктуру.