When you don't work with a given technology for a while, you often find yourself doing the same mistakes time and time again. So, here is a sort of watch list for Hibernate: The Hibernate Gotchas!
http://www.devinprogress.info/2011/08/hibernate-gotchas.html
most projects can be done without hibernate. by introducing hibernate in the middle remember you are adding another man in the middle which needs its onw configs, maintenance, skilled resources/programmers, sql tunning ete etc etc...
The real usecases are so few and far fetched still i find lot of developers for simple web apps force tehmselves to use a OR mapping tool. There is no need. this is like the EJB craze of the 2000s.
most projects can be done without hibernate. by introducing hibernate in the middle remember you are adding another man in the middle which needs its onw configs, maintenance, skilled resources/programmers, sql tunning ete etc etc...
The real usecases are so few and far fetched still i find lot of developers for simple web apps force tehmselves to use a OR mapping tool. There is no need. this is like the EJB craze of the 2000s.
The tech industry has a tendency towards this behavior, so it's nothing new. Those making tools hype it so developers will use it. Then again, it's just human behavior and affects all aspects of life.
Just because things are hyped, does not mean they are bad. The problem is the people.
1. They think things are golden hammers.
2. They think anyone can code and that the BA's, Project Managers, DBAs, Managers, and Business Users are the important ones.
3. They think that because they failed the tool must be to blame
4. They think everyone creates the same sort of applications they do and the same way as them.
5. They think that because they are a good developer, that they make a good architect.
6. They think "never" is better than "always".
You shouldn't use it blindly (as with anything), but I'd say that EJB + JPA (e.g. Hibernate) is actually a good default choice for many types of applications, even or maybe especially the simple ones. Getting a simple object in and out of the DB is trivial in EJB + JPA, but takes a lot of tedious code otherwise.
Only if you have special requirements (millions of records that really represent tabular data, with aggregations, bulk updates etc) then I would consider low-level JDBC.
ORM makes things easier when you know how it works. For me, using JPA2 criteria builder just makes my applications completely typesafe. I just know my queries are right, even when constructed dynamically.
It's an abstraction. Sure, you can do without it, but it's more error-prone. If you know your stuff. I agree that using hibernate or any technology without knowing it correctly is a pain. But ignorance is not an excuse for saying something is wrong.
BTW, why using hibernate directly when you can use JPA and make your application portable?
ORM makes things easier when you know how it works. For me, using JPA2 criteria builder just makes my applications completely typesafe. I just know my queries are right, even when constructed dynamically.
It's an abstraction. Sure, you can do without it, but it's more error-prone. If you know your stuff. I agree that using hibernate or any technology without knowing it correctly is a pain. But ignorance is not an excuse for saying something is wrong.
BTW, why using hibernate directly when you can use JPA and make your application portable?
Are you sure ? What about the famous hibernate proxies ?
Are you sure ? What about the famous hibernate proxies ?
Nothing, your code knowns about nothing about hibernate proxies, so it can run unmodified on any JPA implementation.
Are you sure ? What about the famous hibernate proxies ?
Nothing, your code knowns about nothing about hibernate proxies, so it can run unmodified on any JPA implementation.
Hmm, never had the need for a getClass() of a persistent object or instanceof or typecast, I suppose.
Ooops, my fault, gurus teach that instanceof and typecast are sign of bad design.
- Hibernate Search
- Envers
You shouldn't use it blindly (as with anything), but I'd say that EJB + JPA (e.g. Hibernate) is actually a good default choice for many types of applications, even or maybe especially the simple ones. Getting a simple object in and out of the DB is trivial in EJB + JPA, but takes a lot of tedious code otherwise.
Only if you have special requirements (millions of records that really represent tabular data, with aggregations, bulk updates etc) then I would consider low-level JDBC.
My working experience is we ALWAYS work with bulk of data to process and analyse. So far I do not think any complete system w/o bulk processing of data. Furthermore, using Hibernate together with JDBC just to deal with bulk data is defeating the purpose of using the tool as well. Thus, Hibernate is not my choice always.
The main problem with Hibernate/JPA is that its full of leaky abstractions. JPA in toto is a leaky abstraction. You need to know the configuraton and implementation details in order to use it (the mentioned Gotchas are just the tip of the iceberg).
Moreover, together with Spring, Hibernate/JPA forsters flawed desings like injecting Entities via DAOs into BusunessObjects therby creating tight couplings between database structure and business logic.
Moreover, together with Spring, Hibernate/JPA forsters flawed desings like injecting Entities via DAOs into BusunessObjects therby creating tight couplings between database structure and business logic.
So you are saying the the very thing the allows you to not have a tight coupling is causing tight coupling? What do you think is a business object?
JPA usually means tight coupling of database structure (Entities) to "business logic".
Moreover, together with Spring, Hibernate/JPA forsters flawed desings like injecting Entities via DAOs into BusunessObjects therby creating tight couplings between database structure and business logic.
???
Spring, EJB and CDI all encourage to inject the entity manager, DAOs or other services (depending on the granularity of abstraction that is needed) into "business services", i.e. services implementing business logic.
There is NO tight coupling between the business logic and the DB structure, since it's the very thing JPA abstracts from. Business logic uses JPA entities, JPA entities are mapped to a DB.
Talking about having a tight coupling between "BusunessObjects" and business logic sounds very awkward, since these are the very things that implement it. Maybe "BusunessObjects" means something else in your book than a service implementing business logic?
"Spring, EJB and CDI all encourage to inject the entity manager, DAOs or other services (depending on the granularity of abstraction that is needed) into "business services", i.e. services implementing business logic."
What return EntityManagers and DAOs? The whole database structure as graph of 'Entities'.
"JPA entities are mapped to a DB"
Vice versa. DB records are duplicated to JPA-Entities in the client space. By navigating the JPA-Entity graph you can access the whole database structure (and therefore depend on it). Among other things this makes you "business services" all but untestable.
Vice versa. DB records are duplicated to JPA-Entities in the client space. By navigating the JPA-Entity graph you can access the whole database structure (and therefore depend on it). Among other things this makes you "business services" all but untestable.
Then you are doing it wrong.
Use the right tool for the right job, yes. But this isn't "choose one tool over another" for all your application. You can use both in same application, just for different jobs. ORM is a must for CRUD. It's much better for maintainability and extensibility.
Also, if you guys don't use DDD (Domain-Driven Design) to project your entity classes, you also don't know how to use OOP right and obtain the benefits from it. And just with an ORM you can use full DDD, because your domain entities is real objects. Yeah, it's just that great! If you have a system with lots of business rules, it makes your system much more maintanable (to do the bug killing) and extendable (do the evolution baby).
For batch processing, you can just use stateless (database) sessions (a.k.a entity manager / unit of work pattern) which don't maintain entities in memory or alternatively just use stateful and tune up batch size. If this don't attend you (a rare case for major systems, but a must for financial and billing systems), you can also use SQL directly from the same datasource or stored procedures. The batch isn't your system for most of cases.
Cheers,
--
Wanderson Santos
Use the right tool for the right job, yes. But this isn't "choose one tool over another" for all your application. You can use both in same application, just for different jobs. ORM is a must for CRUD. It's much better for maintainability and extensibility.
Also, if you guys don't use DDD (Domain-Driven Design) to project your entity classes, you also don't know how to use OOP right and obtain the benefits from it. And just with an ORM you can use full DDD, because your domain entities is real objects. Yeah, it's just that great! If you have a system with lots of business rules, it makes your system much more maintanable (to do the bug killing) and extendable (do the evolution baby).
For batch processing, you can just use stateless (database) sessions (a.k.a entity manager / unit of work pattern) which don't maintain entities in memory or alternatively just use stateful and tune up batch size. If this don't attend you (a rare case for major systems, but a must for financial and billing systems), you can also use SQL directly from the same datasource or stored procedures. The batch isn't your system for most of cases.
Cheers,
--
Wanderson Santos
I've used a variety of ORM's and built ORM over the last 8 years. Most JPA compliant ORM aren't well suited to large batch processes that perform ETL. To make an ORM work well for ETL type processes requires doing things differently. For example, look at IBM's Metadata server, which employs model driven design techniques to go from UML to Java/tables. To get batch processes to work well took many years to get right.
Even if a developer uses a JPA compliant ORM in "stateless" mode, the overhead is significant and often times unacceptable. In my own experience, ORM frameworks are useful, but you have to be aware of the limitations of each vendor. It can save time, but that is really a product of the developers and how they use it.
...ETL...
Yes, ETL does present a problem. The best solution is to do the E part as part of the service/repository layer. Move away from moving piles. Sometimes you can't. Thus you end up with duplicate code/logic, tight coupling, etc. For reasons ETL is bad, read pages 169-175 or David Chappell's ESB book.
... ORM frameworks are useful, but you have to be aware of the limitations of each vendor. It can save time, but that is really a product of the developers and how they use it.
That is what my bullet points were saying. :)
And now something about the article, and enough of the trolling...
There is a way the one side of many to one and one to one relationships can be nullable:
The class owning the property referencing the 'one' side of the relationship can be processed with a byte code manipulator. see the 'Workarounds' section of the hibernate doc that was referenced.
There is a way the one side of many to one and one to one relationships can be nullable:The class owning the property referencing the 'one' side of the relationship can be processed with a byte code manipulator.
But bytecode enhancement is "evil", or at least an author of Hibernate once stated this.
You can get away from byte code enhacement in the case of optional one-to-one relation by doing it in a way "by yourself". I came to this solution by myself long time ago and it is mentioned in the workaround section on Hibernate documentation: http://community.jboss.org/wiki/SomeExplanationsOnLazyLoadingone-to-one
Most people want to have such frameworks which help them achieve a buzz word "database independance", but nothing in this world is free. In order to capture this concept, there is always a cost associated with it. Hibernate is a very nice framework only if you don't try to run Ferrari in plough field. For projects with simple usage of entities, it is most recommended but for complex business logic projects it is suggested to use plain old methodologies rather than hibernate.
Suggested by who? It works for me. It works especially well on complex apps.
