🐶
JDBC Templates или JPA
Примечание: обсуждался не чистый JPA, а JPA вместе с Spring Data JPA.
Преимущества JDBC Templates:
- Возможность использования иммутабельных классов;
- Легкость создания кастомных классов-проекций под каждую конкретную ситуацию.
Недостатки JDBC Templates:
- Необходимость самостоятельной сборки объектов;
- Нужно обкладывать каждый запрос интеграционным тестом - мало ли где ты накосячил при составлении sql;
- Приходится поддерживать большое количество кода.
- Сложно рефакторить при любых изменениях в схеме БД.
Преимущества JPA (со Spring Data):
- Быстрота написания кода и как следствие уменьшение трудоемкости написания фичи;
- Восхитительная магия Spring Data, которая позволяет описать запрос в имени метода;
- Джуну тяжело накосячить;
- Легко организовать пагинацию и сортировку с помощью Spring Data.
Недостатки JPA:
- Недостаточный контроль над запросом. Если хочется получить легкие запросы, приходится каждый запрос, генерируемый JPA вендором, просматривать на предмет тормознутости;
- Тяжело разбираться в @EntityGraph;
- Сложность создания проекций.
Применение паттернов проектирования
Изучаешь, изучаешь эти паттерны, а потом никогда их не применяешь :с. Из всего многообразия GOF паттернов большинство присутствующих пользовались только:
- Фасад
- Стратегия
- Адаптер
- Шаблонный метод
- Синглтон (не считается)
Существует интересный паттерн, являющийся объединением цепочки обязанностей и декоратора, который может использоваться, для того чтобы протащить какую-либо сущность через одинаковую последовательность шагов для каждой из операций над сущностью (CRUD и не только).