How useful is Hibernate? Does it make the job much easier?

Question

Java

How useful is Hibernate? Does it make the job much easier?
It is desirable to give vivid examples.
Some articles on Hibernate use SQL queries. Then why use Hibernate if it does not take care of fully automatic database maintenance?
Also in some articles, sessions are constantly opened, actions are performed with the class, and sessions are closed. Doesn't this add more work to the developer? Can Hibernate work in such a way that when a setter is called in a class without creating all sorts of sessions, it would automatically access the database?
Isn't it easier in some cases to write a MySQL query instead of constantly opening sessions?

Answer 1

Useful or not depends on your project. If you have a couple of entities and 10 methods that access the database, then you don't need a hibernate. If you have a large, growing project with dozens and hundreds of entities and a lot of CRUD operations - without JPA, hibernate, spring data, etc. you can't do it. Hibernate greatly simplifies life in simple things, but greatly complicates complex ones. You can also consider the profit of using hibernate as getting a cache of several levels out of the box.
Look at the literature in general on the ORM problem and JPA, without being tied to a specific implementation, which is hibernate.
P.S. And I would not recommend adding any code or logic to the setters. There is a set of commandments of a good developer - SOLID, the first principle is Single responsibility - "each object must have one responsibility and this responsibility must be completely encapsulated in a class". And in your case, there is some kind of model / bin - which contains data in the fields - this is its only responsibility, and the logic for reading and writing to the database should not be of interest to this object in principle.

Answer 2

Look. What gives Hibernate - mapping objects to a relational database. And then there are a lot of questions right away - how to display OOP on a relational model (where there is no inheritance, encapsulation, polymorphism). Hence a lot of difficulty. Still there are such questions - you received an object from the database, transferred it to some UI - the same field was changed there 10 times - so do the database update 10 times or one? Hybernate should guess or the programmer should tell him. From here all sorts of entity life cycles, caches and a bunch of any additional headaches appear. This is if you do not touch on inheritance, one-to-one, many-to-many relationships.
My verdict - hibernate carries a lot of additional burden - it is not in vain that so many books have been written on it.
But it also has its advantages.
In general, any development is a trade off. Therefore, if you want to use a hibernate, you need to clearly understand what it is for.
So pluses
1. You continue to work with the object model and forget about all these 100,000+ lines of sql queries.
2. It's easy for you to add new entities, manage transactions, they think about optimization for you (caches)
3. You generally forgot what joins are and for which fields. You start believing in magic. Quary builders are crazy. And on the groove, the code in one line just drives you crazy!
4. You really have a lot of tables (entities)
5. You got to know hibernate and designed the convention code on the project and generally forgot what problems
are
1. If you have 2 tables - what for to drag a ton of complexities into your project. Look at books on hibernate. A book on only one Java technology. Whole book!!!
2. You must clearly understand the life cycle of the entity. When it is in the session, when it is not, how does it get into the session, what is with the cache, and if the entity has relationships, and if it has lazy loading. Just a ton of everything.
3. You understand that you stop driving requests - and it is unrealistically difficult to optimize something. What to edit in sql with one line - using hibernate it is not surprising if you rewrite the entire inheritance hierarchy with refactoring of controllers, yuja, etc. along the way.
4. At one point, you may realize that you missed the lazy loading topic and started to put the oracle on the shoulder blades. And knowledgeable people will tell you how much it costs to fix it.
5. And yes. If you need a performance - write requests yourself. ORM is clearly not suitable here.
Therefore, just make a table of pros and cons and decide.
Hybernate is only cool when it's justified

Answer 3

the philosophical question is direct)
there are no problems to write your own bindings, and how you speak through setters, for example, update data in database tables (I do this by expanding the standard collections of data types).
On the other hand, we are constantly told not to bike, like smart people have already done all the work, like other developers are used to hibernate, they won’t accept anything else, it will be hard to work in a team, this is the corporate approach.
On your own projects, or on frontline teams, it's okay to write alternative implementations of bindings and other concepts.

Answer 4

I recommend watching this video