Comments 7
Как то не нравится Ebean.find() — вызов статического метода.
А если у меня несколько data sources?
Есть у него интеграция со спрингом?
А если у меня несколько data sources?
Есть у него интеграция со спрингом?
Какая-то интеграция есть, нашел avaje-ebeanorm-spring, хотя сам еще с ней не разбирался.
Также есть неплохие примеры вариантов стиля использования Ebean. Статические методы это просто shortcuts для default сервера. Так-что можно использовать и инстанс без проблем.
Также есть неплохие примеры вариантов стиля использования Ebean. Статические методы это просто shortcuts для default сервера. Так-что можно использовать и инстанс без проблем.
Как лодку назовешь, так она и поплывет. Большую часть времени только и делаешь, что Ebean c Ebean'ом…
Краткое содержание статьи:
Хорошая статья для тех, кто хочет познакомиться с Ebean. Но, на мой взгляд, Ваше мнение о Hibernate лучше бы вообще не упоминали…
Я и еще пара моих знакомых не умеем «готовить» Hibernate и поэтому точно знаем, что Hibernate — гуано. Поэтому мы решили помучаться с Ebean и сделали вот так вот нечто для чего-то. Теперь мы знаем, что Ebean — это круто, потому что хипстер, а Hibernate — все равно гуано, потому что «потому что»
Хорошая статья для тех, кто хочет познакомиться с Ebean. Но, на мой взгляд, Ваше мнение о Hibernate лучше бы вообще не упоминали…
Возможно, не стоило упоминать. Но я не имел ввиду крайностей.
В моем рабочем проекте, который здравствует уже 8 лет есть около 12 подпроектов, 3 с которых успешно работают на Hibernate. Так получилось, что я пришел джуниором (как и мои колеги) и, конечно, же не разобрался с Hibernate, наломал дров. Сеньйоров рядом не было, а стектрейсы Hibernate ужасно напрягали проджект менеджера, который в те далекие времена тоже был «джуниором». Как следствие, на флагманском проекте под давлением «руководства» мы заменили Hibernate на простейший самописный маппер через рефлексию.
Но уверяю вас, я не оставил хвостов. На сегодняшний день, я довольно неплохо разобрался в механике Hibernate. Но повторюсь, что просто он слишком большой ради пары сущностей.
В моем рабочем проекте, который здравствует уже 8 лет есть около 12 подпроектов, 3 с которых успешно работают на Hibernate. Так получилось, что я пришел джуниором (как и мои колеги) и, конечно, же не разобрался с Hibernate, наломал дров. Сеньйоров рядом не было, а стектрейсы Hibernate ужасно напрягали проджект менеджера, который в те далекие времена тоже был «джуниором». Как следствие, на флагманском проекте под давлением «руководства» мы заменили Hibernate на простейший самописный маппер через рефлексию.
Но уверяю вас, я не оставил хвостов. На сегодняшний день, я довольно неплохо разобрался в механике Hibernate. Но повторюсь, что просто он слишком большой ради пары сущностей.
Ясно, спасибо за разъяснение. А можете пояснить насчет "слишком большой ради пары сущностей"? Из личного опыта: я Hibernate применял (и применяю) не только в классических Enterprise-ах, но и микро-проектах, типа утилит, причем некоторые даже для разовых задач. Вполне себе удобно, в любом случае, лучше, чем вручную из ResultSet-ов JDBC вытаскивать данные в свою логику и обратно. Более того, однажды получил мощную оптимизацию, даже сначала не заметив ее, когда Hibernate без указаний с моей стороны применил пакетные обновления сущностей в СУБД. На Ваш взгляд, что именно в Hibernate большое и тяжелое, и на что негативно влияет эта тяжесть?
Забавно, что когда попытался сформулировать мысль почему «большой», понял, что все аргументы лежат в субъективной плоскости, типа «сложнее», «надо помнить про сессии, фетчи», «джарник крупнее, классов больше» и даже просто «не нравится». Отпечаток enterprise оставляет свое впечатление, к сожалению для меня, негативное. Всегда находятся люди, которые «устают» от успешных промышленных фреймворков гигантов, мечтающие о простом API мечты. И это хорошо, ведь создаются альтернативы и разнообразие. Так получилось, что в вопросе Hibernate мое видение с ними сходятся.
Sign up to leave a comment.
Как подружился Ebean с Gradle и помирился с IntelliJ Idea