Подтвердить что ты не робот

Является ли Единица работы и шаблоны хранилища очень полезной для крупных проектов?

Я начинаю новый веб-проект с использованием ASP.NET Webforms + EF4. Я пытаюсь применить шаблон репозитория с единицей рабочего шаблона после этого урока: http://www.dotnetage.com/publishing/home/2011/07/05/6883/the-repository-pattern-with-ef-code-first-dependeny-injection-in-asp-net-mvc3.html

Я думаю, что у меня есть идея, но мой вопрос в том, что, когда я создаю новый объект в модели, мне также нужно определить этот объект в IDALContext подразделения работы? Разве это не призыв к быстрому развитию? Также, если вы работаете с несколькими разработчиками, и если вы не хотите, чтобы другие разработчики видели ваш DAL, как вы можете это сделать? Поскольку в этом шаблоне, как я понимаю, при создании нового объекта в модели вы также должны определить его в IDALContext для этого учебника. Извините, я так смущен этим.

4b9b3361

Ответ 1

Мартин Фаулер описывает роль репозитория как: "Репозиторий посредничает между слоями отображения домена и данных, действуя как коллекция объектов домена в памяти". Что Entity Framework 4.1 предоставляет репозиторий в этом смысле. Кроме того, EF имеет единство работы, встроенной. Поэтому мой совет - игнорировать статью в блоге, которую вы упомянули в своем вопросе.

Код вроде этого не только бесполезен или бесполезен, но и опасен, потому что нет никакой пользы от вашего кода, кроме зависимости!

public interface IUnitOfWork:IDisposable
{
    int SaveChanges();
}

public interface IDALContext : IUnitOfWork
{
    ICategoryRepository Categories { get; }
    IProductRepository Products { get; }
}

Чтобы ответить на ваш вопрос с некоторой абстракцией, которая посредничает между слоями отображения домена и данных, действие, подобное коллекции объектов домена в памяти, является обязательным для "больших" проектов. И наличие механизма UnitOfWork под капотом может помочь отделить вашу бизнес-логику от доступа к некоторой абстракции доступа к данным.

TL; ТР; Репозиторий и UnitOfWork могут помочь вам, но не применять его, как в данном сообщении в блоге.

Ответ 2

Теперь, первый вопрос должен быть , почему мне нужен репозиторий или единица рабочего шаблона вообще? Не мог бы я просто использовать контекст EF с контроллера, имея полную мощность непосредственно написать запрос, который мне нужен, и вернуть данные?
Ответ:. Вы могли бы, но реальная цель - тестируемость и, следовательно, более качественный, более удобный код. Если вы отделите свой доступ к данным и сконцентрируете его на одном месте, вы можете издеваться над ним во время тестирования. Это позволяет вам unit test логику, определенную в вашем контроллере, без эффективной записи в хранилище данных.

Перед тем, как начать работу с Единицей работы, просто используйте обзор Репозитория. Это в основном абстрагирует доступ к данным для данного объекта. Таким образом, вы определяете такие методы, как Filter(), All(), Update (..), Insert (..), Delete (...) и, наконец, Save(). На самом деле большинство из них можно было бы легко абстрагироваться до класса BaseRepository<TEntity>, чтобы в конце концов вам просто нужно было создать новый репозиторий в редких случаях со специальным поведением. В противном случае это будет нечто вроде BaseRepository<Person> personRepo = new BaseRepository<Person>() или BaseRepository<Address> addressRepo = new BaseRepository<Address>() и т.д.

Зачем нужна единица работы?
Единица работы представляет собой все операции, выполняемые в течение определенного цикла, в веб-среде, как правило, для запроса Http. Это означает, что при входе нового запроса вы создаете новую единицу работы, добавляете новые вещи, обновляете или удаляете ее, а затем выполняете "изменения", вызывая .save() или .commit().. что угодно. На самом деле, если вы более подробно рассмотрите Entity Framework DbContext (или ObjectContext), они уже представляют какую-то Единицу работы.
Однако, если вы хотите еще больше отвлечь его, потому что вы не обязательно хотели бы иметь свой EF-контекст в своих классах контроллеров (помните: тестируемость), тогда вы создаете UoW для группировки своих репозиториев, а также для обеспечения того, чтобы все они имели один и тот же EF контекстный экземпляр. Вы можете достичь последнего также через контейнер DI (контейнер для инъекций зависимостей).

На ваши вопросы: полезно ли это в крупных проектах?:
Определенно, особенно в крупных проектах. Все дело в том, чтобы разделять обязанности (доступ к данным, бизнес-логику, логику домена) и, таким образом, сделать вещи проверяемыми.

Ответ 3

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

Итак, каковы проблемы, решаемые шаблоном репозитория?

1- Минимизация повторяющейся логики запросов. В больших приложениях вы можете найти много сложных запросов LINQ, дублированных в нескольких местах. В этом случае вы можете использовать шаблон репозитория для инкапсуляции этих запросов и сведения к минимуму дублирования.

2- Лучшее разделение проблем: Представьте сложный запрос, чтобы получить самые продаваемые курсы в данной категории, которые связаны с загрузкой, объединением, группировкой, фильтрацией и т.д.

Когда вы выполняете такие крупные сложные запросы в своих службах/контроллерах, вы получите в итоге полные сервисы/контроллеры. Эти классы становятся трудными для unit test, поскольку они потребуют много шума. Тесты вашего устройства становятся длинными, жирными и неподъемными.

Если вы столкнулись с этой проблемой, возможно, вы можете использовать шаблон репозитория. В этом примере мы можем инкапсулировать сложный запрос, чтобы получить лучшие курсы продаж в репозитории:

courseRepository.GetTopSellingCourses(int categoryId, int count);

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

3- Развязка архитектуры приложения из фреймворков постоянства:, когда вы используете классы Entity Framework (например, DbContext, DbSet и т.д.) непосредственно в приложении, ваше приложение тесно связано с Entity Framework. Если вы планируете в будущем переключиться на другой O/RM или даже более новую версию Entity Framework с другой моделью, вам может потребоваться изменить многие части вашего приложения, и это может привести к появлению новых ошибок в вашем приложении. Вы можете использовать шаблон репозитория, чтобы отделить архитектуру вашего приложения от инфраструктур персистентности, таких как Entity Framework. Таким образом, у вас будет возможность перейти на другой O/RM с минимальным воздействием на ваше приложение.

Посмотрите это видео для получения более подробной информации:

https://youtu.be/rtXpYpZdOzM