#architecture #entity-framework-4.1 #repository-pattern
#архитектура #entity-framework-4.1 #репозиторий-шаблон
Вопрос:
Я должен построить архитектуру веб-приложения с использованием Entity Framework 4.1 и ASP.NET . У меня уже есть структура базы данных, поэтому я должен использовать database-fist. Я прочитал здесь много статей и тем, но, похоже, я что-то упускаю. Я решил организовать проекты следующим образом:
Я спроектировал веб-приложение с помощью Linq2SQL. Я использовал этот проект. Он предоставляет шаблон T4, который генерирует определенный статический класс репозитория для каждой сущности. Мне нравится этот подход, поскольку легко добавить дополнительную логику в любой репозиторий, например GetUserByName() . Мне нравится этот подход, но я пока не могу найти аналогичный подход для EF4. Я нашел только общие репозитории, а затем мне нужно вручную создавать конкретные репозитории. Что мне не нравится в этом случае, во-первых, то, что у меня есть приложение, над которым я работаю, имеет немного сложную бизнес-логику, поэтому мне придется вручную создавать конкретные репозитории почти для каждого объекта. Во-вторых, если сначала я использую общий репозиторий для получения всех сущностей, а позже мне нужно использовать, например GetUserByName() , тогда в коде будет несоответствие. Я бы предпочел, чтобы все восстановление данных выполнялось одинаково.
Я либо что-то упускаю в архитектурной структуре.
-
Общий: общий репозиторий, если его необходимо разделить
-
DAL: файл EDMX (Entity Model) с классом контекста и репозиториями
-
BLL: бизнес-логика системы
— Сущности
— Сервисы
— и т. д
-
Пользовательский интерфейс: ASP.NET страницы
Вопросы:
-
Правильно ли разделение логики?
-
Должен ли я использовать определенные репозитории?
-
Какую реализацию шаблона репозитория вы бы порекомендовали для лучшей организации проекта и простоты использования?
-
Лучше ли использовать статический репозиторий?
Спасибо
Комментарии:
1. Имея опыт работы с тяжелыми финансовыми системами, разработанными как в Windows, так и в Интернете, я с вами до сих пор, просто небольшой вопрос, почему вы считаете, что ваши сущности должны жить в BLL, насколько я понимаю, сущности — это очень базовая единица, которая облетает почти каждый уровень.
2. Я до сих пор не принял окончательного решения по этому поводу. Я также думал сгенерировать их с помощью EF и поместить их в DAL.
3. @Teddy — такие объекты должны (могли) входить в общий «слой» / сборку, чтобы их можно было использовать повторно; они отличаются от объектов EF, которые специфичны для реализации доступа к данным.
Ответ №1:
Не используйте статические классы в качестве репозитория. Это ужасно и далеко для правильного объектно-ориентированного проектирования. Он также полностью блокирует любую возможность инверсии управления и внедрения зависимостей.
Если вы хотите использовать шаблон репозитория, вы должны использовать определенный репозиторий. Общий репозиторий — это просто оболочка вокруг классов, связанных с EF (где ObjectSet / DbSet уже является репозиторием, зависящим от EF). Вы также должны создавать свой репозиторий поверх совокупных корней, а не поверх каждой сущности.
Комментарии:
1. Спасибо за совет. Знаете ли вы способ создания конкретных репозиториев? Делать это вручную отнимает много времени и немного скучно.
Ответ №2:
Моя предпочтительная настройка:
- Project.Presentation (пользовательский интерфейс)
- Проект.Приложение (уровень приложения, который предоставляет DTO для потребителя / пользовательского интерфейса и выполняет команды для уровня домена)
- Project.Domain
- Сущности [с логикой домена] (заказ, Клиент, …)
- Доменные службы (TransferService, CreditCardService …)
- Интерфейсы репозитория (IOrderRepository, ICustomerRepository, …)
- Проект.Репозитории.EF (доступ к данным с использованием определенной технологии, реализующей интерфейсы репозитория (OrderRepository, CustomerRepository)
- Проект.Инфраструктура (сквозная)