Logo 
Search:

Java Forum

 Ask Question   UnAnswered
Home » Forum » Java       RSS Feeds

Think again before using Hibernate for large scale projects

  Asked By: Matilda    Date: Jul 05    Category: Java    Views: 1819
  

What I deduce from posts in this mailing list, Hibernate seems to be a dominant
persistency solution for most of projects in Iran.

While this is completely reasonable for small or mid-size projects, I would like
my friends to take more caution before deciding to use Hibernate in large scale
projects.

Trough various projects, I have seen that, while Hibernate seems very handy and
promising in the initial steps of the work, it gradually becomes more complex as
project and schema begin to coupe with real world challenges.

Since I'm pretty sure many friends (which are already happy with Hibernate) will
complain I don't want to get much into details but we all know Hibernate fails
to provide enterprise class features that are mandatory for large scale
projects. To name a few; weak query generation, database specific features,
performance and optimal cache and transactional behavior.

In these cases, what happens at the end is that teams begin to migrate their HQL
logic into pure JDBC or stored-procedures in favor of speed which itself result
in a hybrid hard-to-maintain code base.

Although ORM concept is still a big question in computer science, for large
projects I can recommend enterprise class ORMs such as EclipseLink or Cocobase,
query brokers, good old JDBC, stored-procedures, IMDBs, or even non-standard but
super fast set-based API of IMDGs such as those for Coherence.

Share: 

 

1 Answer Found

 
Answer #1    Answered By: Ann Evans     Answered On: Jul 05

I don mean u, dead sure u have lots of experience to have such a deduction, but for those have problem with ORMs or other tools and techs, there is a famous proverb, "A bad workman blames his tools". In software work, the design can make a product brilliant or bring it to the hell, which is highly ignored by us.

Just give u an example, when we use to implement our product using JDBC, we usually had a simple design and code  for handling a master-detail entity, and we are so flexible to implement it however we loved to depends on the scale  of the case.
Maybe if it was a basic info entity we made a selection on all records and filled the master-detail-entity, or we lazily loaded the details  (children) using a different biz method, or whatever, the same in saving data in DB.

Now ORMs simplize the persistence layer for example for this case, by its diferent relational mapping, BUT we should not forget an enterprise  project is so different comparing to a website or a small  project. You should not have a blind trust the implementation of technology vendors, and you have to count any cent on those kinf of projects.
Refering to my master-detail example, ORMs make that easy, but you must handle memory leaking, loading large  valume of data and lots of other pitfalls by choosing appropriate strategy in your analysis/desgin and the implementation.

 




Tagged: