Разрабатываю API на C# (ASP.NET Core). Слой доступа данных разбит на множество модулей (напр. модуль авторизации: содержит модели и репозитории, связанные с авторизацией, модуль библиотека содержит модели и репозитории, связанные с книжками и пр., и т.д.).
Планировалось использовать все эти модули в проекте с API, а всю логику прописывать в контроллерах. Хорошая ли это идея? Или лучше создать отдельный проект, в котором будет описана вся бизнес логика, и в проекте с API использовать его? Если создать отдельный проект для БЛ, то как быть с моделями? Получается, что будут модели БД, модели бизнес логики и модели, которые я буду отдавать/получать от пользователя в API.
Принято делить приложение как минимум на три уровня: доступ к данным, бизнес-логика и UI. В первом: репозитории, БД-контексты и прочая светотень. Во втором: доменные сущности и сервисы. В третьем: вью-модели (которые отдаются и принимаются с фронта), контроллеры (с маппингом вью-моделей на бизнес-сущности и обращения к сервисам), вьюхи и корень компоновки (IoC/DI). Как минимум каждый слой можно выделить в отдельный проект и развязать всё через интерфейсы, которые потом можно собрать IoC-контейнере.
REST-сервис это, десктопное, мобильное приложение или обычный сайт - без разницы.
Конечно, можно фигачить монолит, но рефакторинг постфактум может затянуться.
Контроллер ничего не должен знать про BL, это не его забота, он должен запрос (с данными или без) получить, вызвать соответствующий сервис/хэлпер/любую другую сущность, отвечающую именно за логику и вернуть результат вычислений клиенту.
Если хотите с самого начала разработки привязать ружьё себе поближе к ноге - делайте толстый контроллер, иначе - в первом комменте хорошо расписано как, чего и куда =)
П.С. почему важно отделять сущности в зависимости от их зоны ответственности хорошо написанно тут
Планировалось использовать все эти модули в проекте с API, а всю логику прописывать в контроллерах. Хорошая ли это идея?
Это плохая идея которая противоречит MVC. Контроллер не должен содержать бизнес-логики, он должен лишь содержать логику обработки запроса пользователя и все.
Или лучше создать отдельный проект, в котором будет описана вся бизнес логика, и в проекте с API использовать его?
Нужно ли выносить бизнес-логику в отдельные проект или нет - зависит от того будет ли необходимо ее использование в других проектах или нет. Но вот изолировать слой бизнес-логики от UI-слоя и слоя доступа данных стоит однозначно
Если создать отдельный проект для БЛ, то как быть с моделями? Получается, что будут модели БД, модели бизнес логики и модели, которые я буду отдавать/получать от пользователя в API.
Почитайте про разбитие приложение на слои, DDD и эти вопросы отпадут сами по себе.
