Прежде всего, я хочу прояснить небольшое неправильное представление о бизнес-уровне, так как вы хотите использовать шаблон Repository, и ваша установка является кандидатом на Domain Driven Design , затем бизнес-уровень на самом деле [Модель предметной области ( Сущности и объекты-значения , где вы разрабатываете свою бизнес-логику объектно-ориентированным способом для сущностей и объектов) и прикладной уровень для координации транзакций, операций и команд на уровне домена] Таким образом, предлагаемая архитектура будет выглядеть примерно так:
- Презентация (MVC) [OrderView, OrderPresentationModel, OrderController]
- Приложение [OrderService]
- Использование UnitOfWork (Транзакции) и Репозитории для выполнения логики домена
- DTOs [OrderDTO, CustomerDTO]
- Домен
- Сущности и объекты-значения [Заказ, Клиент, LineItem, Адрес]
- Интерфейсы репозитория [IOrderRepository, ICustomerRepository]
- (необязательно) Интерфейс единицы работы [IUnitOfWork]
- Infrastructure.DataAccess (с использованием ORM или технологии доступа к данным)
- Репозитории [OrderRepository, CustomerRepository]
- (необязательно) Единица работы [UnitOfWork]
- Infrastructure.Common
Пример сценария:
[Презентация] OrderController:
_orderService.CreateOrder(OrderDTO);
[Приложение] Служба заказа:
_unitOfWork.BeginTransaction();
var customer = _customerRepository.GetById(orderDTO.CustomerId);
var order = new Order() { Customer=customer, Price=orderDTO.Price, ... }
_orderRepository.Add(order);
_unitOfWork.Commit();
О ваших вопросах:
1) Является ли предоставление контроля над транзакциями MVC хорошей идеей? На каком этапе должен осуществляться контроль транзакций? Сдается мне, что MVC не должен отвечать за транзакции, но как этого избежать?
Нет, я бы предпочел разделить его на прикладном уровне, чтобы сделать дизайн гибким для поддержки различных презентаций.
2) Должен ли быть какой-то автоматический способ обработки транзакций? Эта реализация ActionFilter является полуавтоматической, но управление транзакциями явно находится в разделе MVC, который не является бизнес-уровнем.
Использовать транзакции на уровне приложений.
3) Класс UnitOfWork совпадает с классом бизнес-уровня?
- если так, значит ли это, что мы можем добавить в него собственные методы бизнес-логики?
- если нет, переносим ли мы единицу работы в какой-либо другой класс (классы), содержащий методы бизнес-логики?
Нет, это просто способ группировки задач в транзакции.
Бизнес-логика фактически инкапсулирована в объектах, и если логика не связана с одним объектом, она должна быть реализована в доменных службах [TransferService.Transfer (account1, account2, amount)], для координации, доступа к репозиториям и транзакций приложения слой это место.