Какой паттерн проектирования вы бы выбрали для типового веб сервиса?
Уже третий проект для меня — веб сервис с базой данных.
В общем случае задача формулируется достаточно просто:
- хранение данных в БД
- CRUD через REST
- более сложная бизнес-логика также через REST
Для решения задачи я обычно использую свой вариант, схожий с MVC:
модель — как правило ORM вместе с валидаторами, прописанными индексами уникальности и т.д.
хелперы — более сложная логика, использующая модель, в которой может быть прописан CRUD или базовые операции (например гарантированное получение записи из БД)
"сервисы" - классы, использующие хелперы (и иногда модель) в которых сокрыта настоящая бизнес-логика
представления - методы, обрабатывающие входящие HTTP запросы, вызывающие "сервисы", форматирующие результат
Мои сомнения и проблемы:
1. Модель сильно привязана к базе данных (будь то mongoDB или MS SQL), и в большинстве случаев её логика (да и вообще логика всей системы) так или иначе подразумевает и учитывает специфику БД.
2. Уровни, которые я описал выше, по сути являются моделью. Контроллера и представлений в их классическом виде нет. Действительно ли они необходимы в этом случае?
3. Юнит тестирование сильно затруднено, если вообще возможно и имеет смысл. Вместо этого я использую поведенческое тестирование с типовыми сценариями работы бизнес-логики (наполнение базы необходимыми данными, выполнение, оценка результата).
Вопросы:
Какой альтернативный вариант проектирования вы бы выбрали? Есть ли какие-либо теоретические выкладки по данному вопросу?
Стоит ли усиливать абстрагирование, чтоб сделать код более "каноническим" и упростить его тестирование?
Отвечу сам себе.
Предварительное штудирование интернетов и вопросы коллегам привели к следующим мыслям:
Для подобных систем подходят шаблоны проектирования "repository" и "query object".
Query object умеет строить запросы к БД, repository умеет работать с коллекциями (и использует query object для построения тел запросов).
Слой логики, который будет на них опираться, и есть та самая бизнес-логика приложения. В моем случае получился интересный эффект - много логики вышло на верхний уровень (что вполне ожидаемо, т.к. репозитории отвечают за довольно примитивные вещи), и БЛ стала напоминать длинные скрипты. В скриптах возникли некоторые повторяемые куски, которые (опять таки с аргументированной позиции коллег) были упакованы в блоки на этом же уровне.
Сложный
