05 Бизнес логика и слои в ASP.NET MVC Core

Современная серверная разработка на платформе ASP.NET MVC Core требует глубокого понимания принципов разделения ответственности между компонентами приложения. Архитектура, основанная на слоях, не только упрощает поддержку кода, но и обеспечивает масштабируемость, тестируемость и гибкость системы. В рамках данной лекции будет детально рассмотрено, как корректно распределять бизнес-логику между контроллерами и сервисами, обрабатывать ошибки с использованием фильтров исключений, а также выносить валидацию за пределы моделей для соблюдения чистоты архитектуры.

Контроллеры в ASP.NET MVC Core традиционно воспринимаются как точки входа для HTTP-запросов. Их основная задача — обработка входящих данных, маршрутизация, вызов соответствующих компонентов и формирование HTTP-ответов. Однако распространенной ошибкой начинающих разработчиков является помещение бизнес-логики непосредственно в контроллеры, что приводит к нарушению принципа единственной ответственности.

Для иллюстрации рассмотрим пример некорректного подхода, где контроллер напрямую взаимодействует с базой данных и содержит логику проверки условий:

В данном коде контроллер берет на себя функции валидации и работы с данными, что усложняет его тестирование и делает систему хрупкой.

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

Такой подход разделяет обязанности: контроллер фокусируется на управлении HTTP-запросами, а сервис — на бизнес-операциях. Это упрощает модульное тестирование, так как сервисы могут тестироваться изолированно от инфраструктуры веб-приложения.

Сервисный слой не ограничивается простой инкапсуляцией операций. В реальных приложениях он часто включает в себя координацию между репозиториями, внешними API, кешированием и другими инфраструктурными компонентами. Например, сервис обработки заказов может взаимодействовать с платежными шлюзами, системами инвентаризации и сервисами нотификаций.

Важным аспектом является проектирование интерфейсов сервисов. Интерфейсы позволяют абстрагироваться от конкретной реализации, что особенно полезно при внедрении зависимостей и написании тестов. В приведенном примере IOrderService определяет контракт, который может быть реализован различными способами — например, для работы с разными СУБД или в режиме мокирования данных.

Обработка исключений — критический аспект надежности приложения. В ASP.NET Core фильтры исключений предоставляют механизм для централизованного перехвата и обработки ошибок, что исключает дублирование кода в каждом методе контроллера.

Рассмотрим сценарий, когда сервис генерирует исключение при нарушении бизнес-правил:

Без использования фильтров разработчику пришлось бы обрабатывать исключения в каждом действии контроллера:

Это приводит к дублированию кода и усложняет поддержку.

Фильтры исключений решают эту проблему, позволяя перехватывать ошибки на уровне всего контроллера или глобально. Пример реализации кастомного фильтра:

Регистрация фильтра в конфигурации приложения:

Теперь любое исключение типа BusinessException автоматически преобразуется в ответ 400 Bad Request с сообщением об ошибке, без необходимости явной обработки в контроллерах.

Фильтры могут быть настроены для работы с различными типами исключений, логирования ошибок, добавления заголовков или даже динамического выбора формата ответа (JSON, XML) в зависимости от запроса. Например, фильтр может логировать критические ошибки в базу данных и отправлять уведомления в Slack, обеспечивая прозрачность работы системы для администраторов.

Валидация данных — неотъемлемая часть бизнес-логики. Хотя атрибуты валидации в моделях ([Required], [Range]) удобны для простых проверок, они не подходят для сложных сценариев, требующих доступа к внешним ресурсам или контексту выполнения.

Например, проверка уникальности email пользователя не может быть выполнена через атрибут, так как требует запроса к базе данных. Решение заключается в переносе таких правил в сервисный слой или использование специализированных библиотек валидации, таких как FluentValidation.

Пример с FluentValidation:

Интеграция валидатора в ASP.NET Core:

Использование в контроллере:

Этот подход отделяет валидацию от модели, делая код более гибким и соответствующим принципам чистой архитектуры.

В микросервисных архитектурах валидация часто требует взаимодействия с другими сервисами. Например, при создании заказа необходимо проверить наличие товара на складе через InventoryService. В таких случаях валидация становится частью бизнес-процесса и должна выполняться в сервисном слое, возможно, с использованием паттерна Unit of Work для обеспечения атомарности операций.

Для закрепления материала рассмотрим полный цикл обработки запроса на создание заказа:

Пользователь отправляет POST-запрос с данными заказа.

Контроллер принимает запрос и передает данные в сервис через интерфейс IOrderService.

Сервис выполняет валидацию, используя FluentValidation, и проверяет бизнес-правила (достаточность средств, наличие товара).

При возникновении ошибки сервис генерирует исключение, которое перехватывается фильтром и преобразуется в HTTP-ответ.

В случае успеха сервис сохраняет данные через репозиторий и возвращает результат контроллеру.

Контроллер формирует финальный ответ клиенту.

Разделение на слои упрощает тестирование. Юнит-тесты для сервисов могут использовать моки репозиториев, интеграционные тесты проверяют взаимодействие с базой данных, а тесты контроллеров фокусируются на корректности HTTP-ответов. Фильтры исключений тестируются через эмуляцию выброса исключений в контроллерах.