Уровень сервиса, уровень репозитория и структура сущностей

Question

Я разрабатываю многоуровневую архитектуру (все слои находятся на одном компьютере) с использованием Entity Framework (сущностей POCO), чтобы использовать те же слои с приложением ASP.Net MVC, мобильным приложением и т. Д.; также для поддержания тестируемости...

У меня будет UI Layer > Service Layer > Repository Layer > Entity Framework > База данных, с Внедрением Зависимостей, абстракцией слоя и разделением задач.

• Предположим, что у меня есть два метода (Customer, Order являются классами сущностей). На каком слое я должен разместить эти методы?

  • public IList GetOrdersByCustomerId(int CustomerId), который содержит запрос LINQ.
    (Уровень репозитория или Сервисный уровень?)
  • public void RequestAnOrderAndStartTheShipmentProcess (Customer CustomerEntity, Order OrderEntity), который выполняет некоторые операции вставки, такие как orderRepository.Add(OrderEntity), shipmentRepository.Add(ShipmentEntity) и т. д.
    (отдельный уровень бизнес-логики или уровень обслуживания?)

• У меня будет интерфейс IOrderService и класс "OrderService: IOrderService" для внедрения зависимостей. Будет ли интерфейс и класс располагаться в одной сборке или должны располагаться в отдельных сборках?

Спасибо

РЕДАКТИРОВАТЬ

Спасибо за Ваш ответ. Но в этом случае возникли четыре вопроса...
1. Если в пользовательском интерфейсе есть ссылка на сборку DataAccess, разработчики могут получить доступ к классам DataAccess непосредственно в коде пользовательского интерфейса, и не следует ли создавать дополнительные усилия для проверки кода (например, если в команде есть младший разработчик)?
2. Я понял, что у меня должен быть метод GetOrdersByCustomerId как на уровне репозитория (выполнение реальных запросов), так и на уровне обслуживания (вызов метода GetOrdersByCustomerId в классе OrderRepository), это правильно?
3. Также я должен выполнить операции CRUD для (почти) всех таблиц, чтобы поддерживать их, и подумать о том, что у меня есть 96 таблиц в моем текущем проекте (это не слишком много, но и не мало), если у меня есть методы Add, Update, Delete в слое сервиса тоже? Или мне стоит подумать о более "поведенческом" уровне моего уровня обслуживания?
4. Я запутался, если в моем OrderRepository есть методы GetOrdersByCustomerById, GetOrdersByStatus и т. Д., Не похоже ли это на класс DAO?

Answer 1

Вы можете рассмотреть архитектуру с тремя сборками (слоями):

Бизнес
Содержит ваши классы обслуживания (а также ваш метод RequestAnOrderAndStartTheShipmentProcess). Бизнес-уровень будет содержать все ваши основные бизнес-правила, и поэтому маловероятно, что вы вдруг захотите заменить этот уровень полностью новым или добавить альтернативу. Поэтому я бы оставил в этой сборке и OrderService, и IOrderService. Я бы также поместил классы POCO (пусть EF автоматически их сгенерирует для вас) и интерфейсы репозитория на этом уровне.

Доступ к данным
Здесь вы храните свои реализации репозитория EF (и ваш метод GetOrdersByCustomerId). Эта сборка ссылается на бизнес-сборку, поскольку она реализует интерфейсы репозитория, обнаруженные на этом уровне.

UI
Здесь вы создаете экземпляры репозиториев из сборки DataAccess и внедряете их в классы обслуживания бизнес-уровня, используя внедрение конструктора. Таким образом, эта сборка имеет ссылки на Business и DataAccess.

Используя эту архитектуру, ваш бизнес-уровень хорошо отделен от других уровней и прост в модульном тестировании. Посмотрите этот ответ для более подробной информации о внедрении зависимостей.

Answer 2

Мое мнение (это всегда немного произвольно):

1. Репозиторий, потому что это типичная заданная операция get для одного набора сущностей.
2. Сервисный уровень, потому что он управляет несколькими операциями над несколькими объектами.
3. Отдельные сборки, так что вы можете добавлять реализации интерфейса из других сборок, не ссылаясь на сборку, которая уже содержит реализацию.