andrushokТак уж и со ВСЕМ? А можно поподробнее? Таки hibernate еще не покинул моих планов ...

Имхо, книжка "hibernate in action" ответит быстрее и на большее число вопросов.

andrushok
1) Hibernate ускоряет разработку простых и средних приложений - Да
2) Hibernate ускоряет разработку сложных приложений - Нет

В книжечке, о которой я упоминал, приводятся рассуждения о не стыковке парадигм возникающей при связывании реляционных баз данных и оо кода.
Там достаточно много иллюстраций в чём эта не стыковка выражается.
Суть всех этих рассуждений одна: если идти на поводу баз данных - теряются все прелести ооп, если идти на поводу у ооп - теряются все приимущества от использования баз данных.
Там же описаны существующие подходы к решению этой проблемы и
ORM признаётся наиболее зрелым из них.

Так же приводится классификация ORM cистем:

Let’s look at the various ways ORM can be implemented. Mark Fussel
[Fussel 1997], a researcher in the field of ORM, defined the following four levels of
ORM quality.
Pure relational
The whole application, including the user interface, is designed around the relational
model and SQL-based relational operations. This approach, despite its deficiencies
for large systems, can be an excellent solution for simple applications
where a low level of code reuse is tolerable. Direct SQL can be fine-tuned in every
aspect, but the drawbacks, such as lack of portability and maintainability, are significant,
especially in the long run. Applications in this category often make heavy
use of stored procedures, shifting some of the work out of the business layer and
into the database.
Light object mapping
Entities are represented as classes that are mapped manually to the relational
tables. Hand-coded SQL/JDBC is hidden from the business logic using wellknown
design patterns. This approach is extremely widespread and is successful
for applications with a small number of entities, or applications with generic,
metadata-driven data models. Stored procedures might have a place in this kind
of application.
Medium object mapping
The application is designed around an object model. SQL is generated at build
time using a code generation tool, or at runtime by framework code. Associations
between objects are supported by the persistence mechanism, and queries may be
specified using an object-oriented expression language. Objects are cached by the
persistence layer. A great many ORM products and homegrown persistence layers
support at least this level of functionality. It’s well suited to medium-sized applications
with some complex transactions, particularly when portability between
Object/relational mapping 25
different database products is important. These applications usually don’t use
stored procedures.
Full object mapping
Full object mapping supports sophisticated object modeling: composition, inheritance,
polymorphism, and “persistence by reachability.” The persistence layer
implements transparent persistence; persistent classes do not inherit any special
base class or have to implement a special interface. Efficient fetching strategies
(lazy and eager fetching) and caching strategies are implemented transparently to
the application. This level of functionality can hardly be achieved by a homegrown
persistence layer—it’s equivalent to months or years of development time. A number
of commercial and open source Java ORM tools have achieved this level of
quality. This level meets the definition of ORM we’re using in this book. Let’s look
at the problems we expect to be solved by a tool that achieves full object mapping.


hibernate - ORM средство из последней категории.

Выгода от его использования тем выше, чем больше требований к ORM системе предьявляет конкретное приложение.
По умолчанию предполагается, что приложение построено согласно layered architecture и что hibernate будет использован в его persistent layer.

Imho,
- в простых приложениях использование hibernate замедлит разработку, проще грамотно спроектировать таблички, процедурки и т.д.
- в средних - в зависимости от опыта работы с hibernate и общих требований к приложению (если не знать достаточно хорошо h* и торопиться, то получится заведомо хуже, чем используя голый jdbc).
- в сложных - без использования hibernate или аналогичного средства просто никуда не денешься.



3) Не рекомендуется мешать hibernate и JDBC - Да

sure, т.к. структура приложения должна быть максимально прозрачна и легко поддерживаема.
добиться этого смешивая два разных подхода к одному и тому же - трудно.


4) Hibernate заменяет понятие RDB на что-то типа "Persistent objetcs in DB" - Да

Я не нахожу смысла в этой фразе.


5) Hibernate не рекомендует использовать native SQL - Да

Так же как не рекомендуется использовать native код в java приложениях.


6) Hibernate работает медленнее, чем если реализовывать через JDBC - Да

В простых приложениях - да, т.к. там достаточно просто
представить все таблички, связи между ними и написать эффективные запросы.
В сложных - нет. Попытки ручного написания sql в этом случае сродни попыткам написания эффективного кода на ассемблере под различные процессоры. Мало того, что это оЧЧень много работы, эта работа может быть проведена в пустую. Правда это теория, на практике я никогда такую работу не делал (оптимизацию sql в сложных аpp).



7) Сей топик породил еще одного (как миниум) hibernato-ненависника - Да

Как мало надо для того, что бы породить какого-нибудь ненавистника :)


8) ООП - панацея на все - Нет

Не понятно зачем такой вопрос ставился.
Есть области, где использование ООП даёт преимущества и есть области, где это не так.