Сообщение Re[4]: Посоветуйте тьюториал по Hibernate от 04.05.2021 7:40
Изменено 04.05.2021 7:42 gyraboo
Re[4]: Посоветуйте тьюториал по Hibernate
Здравствуйте, scf, Вы писали:
G>>"высокая сложность, высокая хрупкость, ограниченное быстродействие" чего именно?
scf>Hibernate, конечно. Впрочем, EclipseLink ненамного лучше.
А в чём тогда логика твоего тезиса? "высокая сложность, высокая хрупкость, ограниченное быстродействие" — *причины* использования JPA (Hiber, EclipseLink)?
Я согласен с тем, что правильно готовить Hiber, чтобы он летал и работал правильно, не так просто, нужно изучать книги, сталкиваться с подводными камнями. Но и JDBC без тюнинга и без понимания механизмов БД тоже будет тормозить (если не использовать индексы или везде лепить join) или будет ненадежным решением (например, если не использовать или неправильно использовать транзакции).
Поэтому правильно приготовленный Hiber не так уж сильно будет отставать от JDBC, но выигрывать в удобстве сопровождения при масштабировании кодовой базы, когда эталонные решения с хибером на проекте уже проработаны.
G>>"высокая сложность, высокая хрупкость, ограниченное быстродействие" чего именно?
scf>Hibernate, конечно. Впрочем, EclipseLink ненамного лучше.
А в чём тогда логика твоего тезиса? "высокая сложность, высокая хрупкость, ограниченное быстродействие" — *причины* использования JPA (Hiber, EclipseLink)?
Я согласен с тем, что правильно готовить Hiber, чтобы он летал и работал правильно, не так просто, нужно изучать книги, сталкиваться с подводными камнями. Но и JDBC без тюнинга и без понимания механизмов БД тоже будет тормозить (если не использовать индексы или везде лепить join) или будет ненадежным решением (например, если не использовать или неправильно использовать транзакции).
Поэтому правильно приготовленный Hiber не так уж сильно будет отставать от JDBC, но выигрывать в удобстве сопровождения при масштабировании кодовой базы, когда эталонные решения с хибером на проекте уже проработаны.
Re[4]: Посоветуйте тьюториал по Hibernate
Здравствуйте, scf, Вы писали:
G>>"высокая сложность, высокая хрупкость, ограниченное быстродействие" чего именно?
scf>Hibernate, конечно. Впрочем, EclipseLink ненамного лучше.
А в чём тогда логика твоего тезиса? "высокая сложность, высокая хрупкость, ограниченное быстродействие" — *причины* использования JPA (Hiber, EclipseLink)?
Я согласен с тем, что правильно готовить Hiber, чтобы он летал и работал правильно, не так просто, нужно изучать книги, сталкиваться с подводными камнями. Но и JDBC без тюнинга и без понимания механизмов БД тоже будет тормозить (если не использовать индексы или везде лепить join) или будет ненадежным решением (например, если не использовать или неправильно использовать транзакции).
Поэтому правильно приготовленный Hiber не так уж сильно будет отставать от JDBC, но выигрывать в удобстве сопровождения кода (т.е. кода писать и поддерживать придется меньше чем на jdbc, и велосипедов будет меньше чем придется их писать на jdbc, т.к. у хибера (плюс спринг конечно) многое из коробки) при масштабировании кодовой базы, когда эталонные решения с хибером на проекте уже проработаны.
G>>"высокая сложность, высокая хрупкость, ограниченное быстродействие" чего именно?
scf>Hibernate, конечно. Впрочем, EclipseLink ненамного лучше.
А в чём тогда логика твоего тезиса? "высокая сложность, высокая хрупкость, ограниченное быстродействие" — *причины* использования JPA (Hiber, EclipseLink)?
Я согласен с тем, что правильно готовить Hiber, чтобы он летал и работал правильно, не так просто, нужно изучать книги, сталкиваться с подводными камнями. Но и JDBC без тюнинга и без понимания механизмов БД тоже будет тормозить (если не использовать индексы или везде лепить join) или будет ненадежным решением (например, если не использовать или неправильно использовать транзакции).
Поэтому правильно приготовленный Hiber не так уж сильно будет отставать от JDBC, но выигрывать в удобстве сопровождения кода (т.е. кода писать и поддерживать придется меньше чем на jdbc, и велосипедов будет меньше чем придется их писать на jdbc, т.к. у хибера (плюс спринг конечно) многое из коробки) при масштабировании кодовой базы, когда эталонные решения с хибером на проекте уже проработаны.