One of the most complicated and time-consuming tasks of developing an enterprise application is writing the code to store and load data from a database at the appropriate times. Hibernate is the right tool to remedy this.
Hibernate is a powerful, ultra-high performance object/relational persistence and query service for Java. Hibernate lets you develop persistent classes following common Java idiom - including association, inheritance, polymorphism, composition, and the Java collections framework. Hibernate allows you to express queries in its own portable SQL extension (HQL), as well as in native SQL, or with Java-based Criteria and Example objects.
Hibernate allows us mapping an object model to a relational schema, keeping object model and database schema in sync. It also makes us easy persisting and retrieving an object from database.
www.hibernate.org
1 comment:
Java persistence technology is a very vibrant ecosystem of competing technologies (JDBC, JDO, EJB CMP, Hibernate, etc). There is an unfortunate trend in Java to focus on the range of alternative technologies available for Java persistence, rather than the more important issue of the Java persistence architecture. If you look at industry forums such as The Server Side, you can see regular battles between proponents of Hibernate and Java Data Objects (JDO).
While this is interesting for Java developers, there are a number of problems for project managers and sponsors with focusing on the technology choices. The most obvious problem is that when the main focus is on the technology choice, it means that there is less focus on the more important issue of application architecture.
Java persistence technology is evolving all the time. What may look new and exciting now will be replaced or upgraded, and probably sooner rather than later. This means that applications must be architected to allow for the Java persistence technology to be changed without affecting any other part of the application code.
Another problem is that the there is no perfect technology choice. All of the alternatives have technical strengths and weaknesses.
The choice of Java persistence technology is not simply a technical decision. Project managers need to also consider some non-technical factors:
Skills
The availability of the appropriate skills for staffing a development project and ongoing maintenance is an important consideration for a project manager. Software engineers, of course, will always be keen to learn the latest and newest technology, but project managers usually have different ideas about the best use of time.
Risk
Project managers and architects, unlike developers, also need to consider the risk factors in a particular choice of technology. Customers may not be happy to use the latest technology. For example, a customer may prefer to use a mature and stable technology like JDBC rather than the first version of the EJB 3.0 specification (preferring to wait until any issues are sorted out with EJB 3.1). This is not exciting for developers.
Legal
A project sponsor may have opinions about using open source solutions (for example, legal restraints on redistribution). Also, conservative organizations sometimes prefer to have technical support contracts (now possible for a range of open source products).
Deadlines
If a project has a tight deadline, it’s probably not the best idea to start investigating new Java persistence technologies. Tight deadlines mean that project managers want the technology that requires the least amount of time for configuration, etc. CodeFutures answer to tight deadlines, of course, is to automatic code generation.
Data Access Objects – The Project Manager’s Insurance Policy
The Data Access Object (DAO) design pattern provides a technique for separating object persistence and data access logic from any particular persistence technology or API. DAOs are an architectural strategy rather than a technology choice. DAOs are a Core J2EE Design Pattern, which means that they are well known and accepted.
The DAO design pattern also provides a simple, consistent API for data access that does not require knowledge of JDBC, EJB, Hibernate, or JDO interfaces. This helps considerably with longer term maintenance.
DAOs offer clear benefits from an architectural perspective. The DAO approach provides flexibility to change an application's persistence technology over time without the need to re-engineer application logic that interacts with the DAO tier. For example, there may be performance benefits in changing an application’s performance mechanism from using Entity Beans to using direct JDBC calls from a session bean, or even a move to an alternative persistence framework, such as JDO or Hibernate. Without a DAO tier in place, this sort of transition would require extensive re-engineering of existing application code.
DAOs make applications easier to maintain because when databases are upgraded, persistence technologies change, or persistence technologies are replaced, the only part of the application that is affected is the DAO tier. And when the DAO tier is automatically produced using a code generator, upgrades and maintenance become almost trivial compared with the technical difficulties of changing the Java persistence code that is embedded directly in an application.
Post a Comment