UOW и шаблон репозитория в EF5

Речь идет о некотором замешательстве, которое у меня есть по поводу некоторых материалов по структуре сущностей, которые я нашел здесь: https://www.asp.net/

На этой странице объясняется, как обернуть dbcontext с помощью репозитория и обернуть репозиторий с помощью единицы рабочего класса: http://www.asp.net/mvc/overview/older-versions/getting-start-with-ef-5-using-mvc-4/implementation-the-repository-and-unit-of-work-patterns-in-an-asp-net-mvc-application

Однако на этой странице указано, что dbcontext уже представляет собой комбинацию шаблона UOW и шаблона репозитория: https://msdn.microsoft.com/en-us/library/system.data.entity.dbcontext(v=vs.103).aspx

Итак, если проблема, которую решают эти шаблоны, уже решена с помощью dbcontext, зачем повторно реализовывать эти шаблоны с помощью EF5?

Кроме того, в учебнике класс UnitOfWork, похоже, не показывает каких-либо преимуществ, которые должен дать UOW. например, в нем говорится: «Таким образом, когда единица работы завершена, вы можете вызвать метод SaveChanges для этого экземпляра контекста и быть уверенным, что все связанные изменения будут скоординированы».

но все, что он, кажется, делает, это обертывает dbcontext без всякой причины. Я думаю, что что-то упускаю. Я не вижу в этой реализации согласованности ... А как сделать "откат", если что-то пойдет не так?


c# asp.net-mvc entity-framework-5
person user1809104    schedule 30.04.2015    source источник
comment
Я удивляюсь тому же каждый раз, когда вижу вопросы с терминами «единица работы» или «репозиторий» в сочетании с тегом entity-framework. Я буду смотреть это ... +1   -  person spender    schedule 30.04.2015
comment
@spender Ага, забавно, как много людей пытаются добавить еще один уровень абстракции поверх того, что уже абстрагирует для них базу данных. Я не верю, что OP в этом вопросе оценил мой answer много. Я тоже буду с интересом следить за этим вопросом.   -  person Alex    schedule 30.04.2015
comment
возможный дубликат stackoverflow.com/q/14110890/1515209   -  person qujck    schedule 30.04.2015

Ответы (4)


arrow_upward
4
arrow_downward

Не используйте другой уровень абстракции UoW / репозитория

Как правильно указал OP, Entity Framework (аналогично, например, NHibernate и другим ORM) уже предоставляет вам абстракцию базы данных с транзакционной «единицей работы» и «репозиториями», которые вам доступны.

Дополнительный уровень абстракции UoW / репозитория - это анти-шаблон, которого следует избегать любой ценой. С этим связано множество проблем, самые важные из которых:

  • они мешают вам использовать всю мощь базового ORM (ленивая загрузка, жадная загрузка, сложные запросы и т. д.)
  • если они хотят предоставить какие-либо дополнительные преимущества помимо простого CRUD, они будут «дырявыми» (т. е. отражать возможности, присутствующие в базовом ORM).

Но, но, но ...

Мне нужно иметь возможность модульного тестирования, издевательства над моими репозиториями

Нет, не знаешь. Просто используйте для этого базу данных с содержанием, специфичным для вашего теста. Используйте базу данных в памяти (например, SQLite, Усилия, ...), если вы хотите, чтобы это было быстрее.

EF не применяет бизнес-логику, которая не выражается в отношениях данных ... Чтобы реализовать этот тип логики, вы должны создать OUW / Repository / оба в некотором роде вокруг контекста EF.

Нет, не надо. Реализовать бизнес-логику на уровне абстракции инфраструктуры, таком как единица работы или репозиторий, просто неправильно.

  • Ценная бизнес-логика принадлежит объектам домена, службам домена, командам домена или долгосрочным бизнес-процессам, сагам.
  • Простые проверки (т.е.не null, значение между x и y) не работают: они должны решаться на границах вашего системного интерфейса.

Также обратите внимание, что простые действия в стиле CRUD без какой-либо ценной бизнес-логики не нуждаются в прохождении всех «звеньев», т. Е. Избегайте этого шаблона:

  1. База данных → Сущность без поведения → DTO → Модель представления → Просмотр
  2. Редактировать поля
  3. Просмотр → Просмотр модели → DTO → Сущность без поведения → База данных

Просто загрузите его прямо из ORM в свой контроллер в форме «Модель представления», необходимой для представления, и сохраните ее прямо из контроллера.

Об абстракциях

Такие ненужные абстракции и обручи слоев - зло. Они запутывают ваш код, связывают вам руки, протекают, увеличивают размер кода и, следовательно, количество ошибок в вашем коде, не обеспечивая при этом никакой дополнительной ценности.

Используйте абстракции, когда они предлагают вам дополнительную ценность, например когда они вам нужны для решения сквозных проблем, сбора повторяющихся шаблонов в вашей архитектуре и управления ими, ...

Создание абстракций ради абстрагирования - пустая трата времени.

person Alex    schedule 30.04.2015

arrow_upward
2
arrow_downward

Я уже много писал об этом здесь, но резюмирую для вас. Да, Entity Framework уже реализует шаблоны UoW (DbContext) и репозитория (DbSet). Нет никакой пользы от их повторного внедрения еще раз. Фактически, это большой ущерб, поскольку он значительно увеличивает накладные расходы на обслуживание вашего проекта.

Почему Microsoft включила это во вводные руководства? Честно говоря, я не уверен, но это была ошибка, которая преследовала бесчисленное количество новых разработчиков MVC, включая меня, когда я только начинал.

Есть преимущество в некоторой абстракции, так что ваш проект не зависит от какого-либо одного конкретного способа получения данных. Однако эта абстракция должна возвращать конкретные данные, которые нужны вашим действиям, ни больше, ни меньше. За неимением лучшего слова я называю это «услугой», хотя Microsoft придала этому слову совершенно другое значение через SOA. Проще говоря, это похоже на то, как если бы вы просто создавали API для своего приложения, как если бы вы создавали веб-API, только полностью на основе кода (не требующего фактического HTTP-соединения). Затем он переходит в ваш слой DAL (библиотеку классов или аналогичный), на который может ссылаться ваш проект.

person Chris Pratt    schedule 30.04.2015

arrow_upward
0
arrow_downward

Особенность EF в том, что в функциональности OUW или репозитория, которую он предоставляет, нет бизнес-логики. Если вы вызовете SaveChanges, он с радостью сохранит все изменения. Однако существует требование, что при добавлении, скажем, виджета, необходимо добавить Frobber для виджета, вам не повезло (если не задействована зависимость FK). Для любой части бизнес-логики, которая не выражается в отношениях данных, EF из коробки не применяет ее.

Чтобы реализовать этот тип логики, вы должны создать OUW / Repository / оба в некотором роде вокруг контекста EF. Это единственная причина, по которой вы сделали это, насколько мне известно.

person simon at rcl    schedule 30.04.2015

arrow_upward
-2
arrow_downward

шаблон единицы работы и репозитория не имеет отношения к работе фрейма сущности. это один из шаблонов проектирования. поэтому он используется для того, чтобы сделать ваш код более читаемым, повторно используемым и эффективным, а также этот шаблон используется для достижения single-time (одноразовое создание объекта), а также для предотвращения инверсии управления.

person Muddassar Hayat    schedule 30.04.2015