Comments 14
В этой статье я использую версию 1.3.0.M1.
Что это за древность? Уже есть релиз — 2.1.2.RELEASE
Возможно, я старомоден, но мне кажется спорным использование генерации приложения через spring init, ровно как и использование спринговой (а если быть точнее, то spring-data) магии вроде интерфейсов репозиториев, где методы магическим образом реализуются сами на основе имени, без понимания того, как реально это работает внутри.
Совершенно согласен, коллега. Силами пиарщиков у программеров создается стойкое впечатление, что любой проект на Java — это обязательно Spring. На самом деле Spring (Boot) — это про то, как максимально быстро и кратко написать приложение "Hello world" с кучей подключенных технологий. Когда же дело доходит до реальной бизнес-логики, вся эта подковерная магия начинает сильно мешать, а программирование превращается в рыскание по stackoverflow в поисках магических рецептов и заклинаний. В частности, вместо магии SpringData гораздо удобнее испльзовать type-safe обертки типа Morphia + QueryDSL или Hibernate OGM, нежели репозитории с магическими findBy.
На самом деле «магия» SD JPA состоит из десятка простейших регулярок, и всё. Никаких слишком умных компиляторов методов-в-SQL, ничего. Если знаешь, как отрабатывают регулярки под капотом, процесс написания совершенно прозрачный. Если оно чего-то не умеет, то просто не умеет и всё, можно даже не копаться на Stackoverflow в тщетных попытках.
Наверное, потом надо запилить про это статью, а то у людей постоянно баттхерт пылает.
Это все понятно, но я не понимаю, если брать например JPA, чем EntityRepository.findByXXX() концептуально лучше EntityManager.createQuery(...).getResultList()? Когда количество сущностей в модели данных близится к нескольким десяткам, а запросы становятся не такими тривиальными, SD уже начинает мешать, а потом сильно мешать. Количество объектов-репозиториев стремится также к нескольким десяткам, а некоторые из них быстро становятся общей помойкой всевозможных методов из совершенно разных бизнес-задач.
Уж простите, никакой гениальности в SD я не вижу. Это не ORM, ни даже полноценный генератор запросов а некий конструктор фильтров. И у разработчиков отнюдь не стояла задача сделать его удобным для большого круга задач. Им нужен был минимальный леер, чтобы на базе него интегрировать как можно больше технологий хранения и поставить галочки.
По первому кейсу согласен — когда нужно быстро поднять микроприложение с минимальным набором требований, которые полностью покрываются SD, то почему нет.
Во-втором случае все наоборот — кейс настолько нетипичен, что SD будет только мешать. В частности, SD требует создавать DAO-репозиторий на сущность, тогда как в вашем случае хочется иметь в одном репозитории все методы, относящиеся к конкретной завершенной бизнес-задаче. Более того, многие агрегированные запросы не относятся вообще ни к какой конкретной сущности, поэтому не совсем ясно в какой репозиторий их поместить. Ну и, наконец, для этого есть более подходящие технологии, например JDBI.
Может, конечно, «вы не умеете их готовить», но…
- Непривычный синтаксис (NoSql, чтоб его...)
- Низкая скорость записи. Блокировать всю коллекцию при добавлении документа — это круто.
- Невозможность создания ссылок на другие коллекции
- При восстановлении базы из бекапа (пара терабайт объемом) MongoDB благополучно падала
- Слабый функцонал Spring Data. Да, на CRUD вполне хватает, но какие-то запросы посложнее приходилось создавать с ощутимым напрягом
Это только то, что вспомнилось с лету.
Но, самое главное — в чем смыл такой связки?
MongoDB предназначена для хранения документов произвольной структуры.
Но Java-то этого не умеет!
То есть, мы или храним документы одной и той же формы (тогда зачем нам MongoDB?), либо скатываемся до безтиповых данных, работая с документом как с Map (что чревато).
Введение в Spring Boot с Spring Data Mongo