In a nutshell, object/relational mapping is the automated (and transparent) persistence of objects in a Java application to the tables in an SQL database, using metadata that describes the mapping between the classes of the application and the schema of the SQL database. In essence, ORM works by transforming (reversibly) data from one representation to another. Before we move on, you need to understand what Hibernate can’t do for you.
A supposed advantage of ORM is that it shields developers from messy SQL. This view holds that object-oriented developers can’t be expected to understand SQL or relational databases well and that they find SQL somehow offensive. On the contrary, we believe that Java developers must have a sufficient level of familiarity with—and appreciation of—relational modeling and SQL in order to work with Hibernate. ORM is an advanced technique used by developers who have already done it the hard way. To use Hibernate effectively, you must be able to view and interpret the SQL statements it issues and understand their performance implications.
■ Productivity — Hibernate eliminates much of the grunt work (more than you’d expect) and lets you concentrate on the business problem. No matter which application-development strategy you prefer—top-down, starting with a domain model, or bottom-up, starting with an existing database schema—Hibernate, used together with the appropriate tools, will significantly reduce development time.
■ Maintainability — Automated ORM with Hibernate reduces lines of code (LOC), making the system more understandable and easier to refactor. Hibernate provides a buffer between the domain model and the SQL schema, insulating each model from minor changes to the other.
■ Performance — Although hand-coded persistence might be faster in the same sense that assembly code can be faster than Java code, automated solutions like Hibernate allow the use of many optimizations at all times. One example of this is efficient and easily tunable caching in the application tier. This means developers can spend more energy hand-optimizing the few remaining real bottlenecks instead of prematurely optimizing everything.
■ Vendor independence — Hibernate can help mitigate some of the risks associated with vendor lock-in. Even if you plan never to change your DBMS product, ORM tools that support a number of different DBMSs enable a certain level of portability. In addition, DBMS independence helps in development scenarios where engineers use a lightweight local database but deploy for testing and production on a different system.
The Hibernate approach to persistence was well received by Java developers, and the standard Java Persistence API was designed along similar lines.
JPA became a key part of the simplifications introduced in recent EJB and Java EE specifications. We should be clear up front that neither Java Persistence nor Hibernate are limited to the Java EE environment; they’re general-purpose solutions to the persistence problem that any type ofJava (or Groovy, or Scala) application can use.
The JPA specification defines the following:
■ A facility for specifying mapping metadata—how persistent classes and their properties relate to the database schema. JPA relies heavily on Java annotations in domain model classes, but you can also write mappings in XML files.
■ APIs for performing basic CRUD operations on instances of persistent classes, most prominently javax.persistence.EntityManager to store and load data.
■ A language and APIs for specifying queries that refer to classes and properties of classes. This language is the Java Persistence Query Language (JPQL) and looks similar to SQL. The standardized API allows for programmatic creation of criteria queries without string manipulation.
■ How the persistence engine interacts with transactional instances to perform dirty checking, association fetching, and other optimization functions. The latest JPA specification covers some basic caching strategies.
Hibernate implements JPA and supports all the standardized mappings, queries, and programming interfaces.
UfautrucOin-dzu Mandy Lewis click
ReplyDeletelopacovab