Use hibernate3 as a JDBC framework

Author: Gavin King Translation: ChiKai recently around the simple JDBC framework, as iBATIS, there are always some loud noise. In my personal point of view, in a single transaction, there is a unpredictable diagram between the entities, and does not need to object-oriented the application of object-oriented domain mode, I like Ibatis. If you are working on some of the "very stupid" legacy database issues, a JDBC framework can also produce strong judgment. ORM solutions are more tended to assume those entities that are more clearly integrated with the same correct integrity constraints (Hiberante3 is much less than hibernate2.x). Some people even suggesting that the JDBC framework is a better option for ORM, and even for those most suitable ORM-oriented systems: the object-oriented system with a clear relationship model. They persuaded themselves, your handwritten SQL code total It will be better than the generated SQL condition. I don't think this is correct, not just because most applications need to have an overwhelming SQL code that is monotonous, and does not need people to interfere, but because the JDBC framework is in ORM. Semantic level works. As a solution, IBATIS is very little about SSL release of SQL and as a result of the result. This means that very few timings are for performance optimization, such as effective caching, (according to "effective", I will have a generally effective cache invalid policy, which is critical to the use of cache). Moreover, whenever we handwritten SQL, we all know the Selects issue of N 1. That is very monotonous to handwritten a new SQL query for each association that I may need to connect together. HQL has a helpful help in this regard, because HQL is never detailed than SQL. If, a JDBC framework can do the informality optimization that ORM can do, which will have to become a level similar to sophistication. Essentially, it will need to be an ORM to reduce SQL production. In fact, we have begun to pay attention to this evolution of the existing JDBC framework. This begins to erode any of the benefits: simple demand. This will also increase the interest of the following questions: If, gradually increase the raw material, a JDBC framework will end as an ORM, reduce the generation of SQL, why not accept an existing ORM solution? Just like, huh, um, hibernate, perhaps ... and subtract SQL production. After long-term verification, the Hibernate team requires mixing and matching to generate SQL to handwind queries in special occasions. In the old version of Hibernate, our solution is to simply expose the JDBC connection that Hibernate is using, so you can perform your own predued statement. This will have just started changing, Max. Andersen has recently done a lot of work in this regard. Now, in Hibernate3, write a application entity that does not produce SQL will be possible, and all other features of Hiberante can still be used at this time. We really expect and plan to use Hibernate in this way? Well, it's not true - I suspect that there are many people who will really enjoy the full day of INSERT, UPDATE, DELETE statement. On the other hand, I also think that quite small people need to customize the query of special occasions. In addition to every proven, I will show you how to use hibernate, if you really want to do it.

Let's take a simple person-Employment-Organization domain mode as an example, (you can find these code in the org.hibernate.teest.sql test package, so I don't plan to copy them here.) The easiest The class is Person; here is its mapping file: < / id> Insert Into Person (Name, ID) VALUES (Upper (?), ?) Update Person Set Name = Upper (?) Where id =? DELETE FROM PERSON WHERE ID =? First we have to pay attention to the handwritten insert, update and delete statement, this? The order of the parameters is that matching the attributes listed above (we will have to support the specified parameters, I guess). I guess this is nothing to be interested in places. More is interested in this tag: it defines a reference to the specified query when we use get (), load (), or latency to load a Person entity. Special, this specified query may be a native SQL query, since this, the following is: Select name as {p.name}, id as {p.id} from person where id =? For update (native SQL query may return multiple "columns" of entities; this is the most Simple example, only one entity is returned here.)

Employment is a bit of complex, special, not all attributes being included in Insert and Update statements:

INSERT INTO Employment (Employee, Employer, StartDate, Regioncode, ID) VALUES (?,?, current_date, Upper (?),?) Update Employment Set enddate =? Where id =? DELETE FROM EMPLOYMENT WHERE ID =?

SELECT EMPLOYEE AS ​​{emp.employee}, EMPLOYER AS {emp.employer}, STARTDATE AS {emp.startDate}, ENDDATE As {Emp.Enddate}, regioncode as {emp.regioncode}, ID as {emp.id} from Employment WHERE ID =? There is an Employments in the Organization entity. Collection Collection Collection: INSERT INTO Organization (Name, ID) VALUES (Upper (? ),?) Update Organization Set Name = Upper (?) WHERE ID =? DELETE FROM Organization WHERE ID =?

The query is not just for the Organization object, but also for its Employments collection: select name as {Org .name}, ID as {org.id} from organization where id =? < return alias = "emp" class = "Employment" /> SELECT {empcol. *}, EMPLOYER AS {emp.employer}, EMPLOYEE AS ​​{emp.employee}, STARTDATE AS {emp.startDate}, ENDDATE AS {emp.endDate }, Regioncode as {emp.regioncode}, id as {emp.id} from Employment Empcol where Employer =: id and deleted_datetime is null When I write this code, I really start feeling to make Hibernate Help me write these SQL benefits. In this simple example, I will have already excluded the code that has to be supported after 35 lines. Finally, for a special query, we can use a native SQL query (a specified query, or code embedded in Java). Examples are as follows: SELECT DISTINCT NAME AS {org.name}, ID AS {org.id} FROM ORGANIZATION org INNER JOIN EMPLOYMENT e on e.employer = org.id I would rather write code in XML in Java, for my hobby, so all raw materials are so large amounts of bloated XML. I think I will adhere to the generation of SQL, no matter where it is. That is not because I don't like SQL, in fact, I am a SQL fanatic fan, just like when I open Hibernate logistics. That's because hibernate will write code than I will write.