On Hibernate
Hibernate is an Object-Relational mapping tool. You see, Java Enterprise systems are designed using the Object Oriented way. Whereas databases are designed using the relational DB way. These are two different paradigms. RDBMSes consists of flat tables that relate to one another. OO is much richer than that. You have inheritance, interfaces, superclasses and subclasses. It's a nightmare to translate OO to RDBMS and vice versa.
Hibernate does all that for developers - alleviating the painful task of writing routine mundane plumbing codes just so that you can save your application data into the database. Writing SQL codes are the most tedious and painful part of Java Enterprise Application development. In FCP (our product), lots of records such as membership information, plan information, provider information and such can be 'automagically' handled by Hibernate without us writing a single line of SQL code. We instead can focus on SQL queries that require fine-tuning and complex cross-table referencings.
I had filed in a proposal to 'convert' most of our database accesses to use Hibernate. And we've went live with our feasibility/impact studies and prototyping. The result was good, and we're going to get contract staff to rebuild the system's back end within the next few months. The thing that really got people's attention is the automatic performance tuning and database-independence that Hibernate brings.
But something really amazed me today.
I was browsing theserverside.com when I found out that the EJB 3.0 specs has been announced, and they're going to drop the complex bean specs in favour of a simple POJO-based model that is no different from Hibernate!!
This is good news.
I wanted to use Hibernate because it's too hard to maintain a system full of thousands of SQL queries. We want our developers to be 'lightly loaded'. So having automagic tools like Hibernate helps. Another pet-idea of mine is to use XDoclet to automagically generate codes for us. Right now about half of our code is in the form of EJBs that can be generated automatically. I haven't gotten the chance to do feasibility study on this though.. but it'd be interesting when this happens.
Neat!
Full Article: Politically Charged EJB Decision Hands a Victory to JBoss
Hibernate does all that for developers - alleviating the painful task of writing routine mundane plumbing codes just so that you can save your application data into the database. Writing SQL codes are the most tedious and painful part of Java Enterprise Application development. In FCP (our product), lots of records such as membership information, plan information, provider information and such can be 'automagically' handled by Hibernate without us writing a single line of SQL code. We instead can focus on SQL queries that require fine-tuning and complex cross-table referencings.
I had filed in a proposal to 'convert' most of our database accesses to use Hibernate. And we've went live with our feasibility/impact studies and prototyping. The result was good, and we're going to get contract staff to rebuild the system's back end within the next few months. The thing that really got people's attention is the automatic performance tuning and database-independence that Hibernate brings.
But something really amazed me today.
I was browsing theserverside.com when I found out that the EJB 3.0 specs has been announced, and they're going to drop the complex bean specs in favour of a simple POJO-based model that is no different from Hibernate!!
This is good news.
I wanted to use Hibernate because it's too hard to maintain a system full of thousands of SQL queries. We want our developers to be 'lightly loaded'. So having automagic tools like Hibernate helps. Another pet-idea of mine is to use XDoclet to automagically generate codes for us. Right now about half of our code is in the form of EJBs that can be generated automatically. I haven't gotten the chance to do feasibility study on this though.. but it'd be interesting when this happens.
Neat!
Full Article: Politically Charged EJB Decision Hands a Victory to JBoss
0 Comments:
Post a Comment
<< Home