Thinking about the Hibernate,jdbc,sql

SQL 1. Object and database mapping, the key is the mapping of object relationships, but not ideal, too much configuration, control complex, and there will be errors. In fact, the essence is that the object is not free.

2. Transaction processing. This is more prone to problems, compared to a variety of transaction managers, to be compatible is a big problem, always in a variety of application servers have a lot of problems. Its essence is to create a small data access environment, the inevitable face of a variety of compatibility issues.

3.HQL language. Create object Query Language, class SQL, but unlike any SQL, debugging environments are complex. The essence is to create a language that increases the cost of learning.

The hibernate is reduced to a SQL generator, which can preserve the primary functions as well as the various application servers and database servers, and no need to learn the HQL language.

Just a series of functional functions, a wrapper, and a different SQL based on different databases, without specifying the database type, because database type properties can be obtained from connection.

Supposedly in the API:

The public object Resultmapobject (ResultSet rs,string XML)//line maps a single object that can be bound with XML or not.

The public List sqlmapobjects (Connection conn,string []sqls,string XML)//maps a bunch of SQL to an object tree, you can describe the bindings in XML, or you can use only the conventions of the Ror method.

Use JDBC and SQL to build the entire data access layer.

Maps a single object's code to map a row of records to a single object. SQL can be arbitrary.

Connection conn=drivermanager.getconnection (URL);
PreparedStatement PS = conn.preparestatement (SQL);

ResultSet rs = Ps.executequery ();
while (Rs.next ())
{
User= (Users) Resultmapobject (RS);
TODO can use the user
}

Map the object tree.

/*
Sale_orders Sales Order Form
Sale_order_details Sales Order Detail Table
Products List
Product_catalogs Commodity Category Table
From SQL, you can analyze
ID is the primary key
Sale_order_details.sale_order_id===>sale_orders.id
Sale_order_details.product_catalog_id==>product_catalogs.id
Sale_order_details.product_id==>products.id
*/
string []sqls=new string []{
"SELECT ID, Total_sum, Memo, State, Modify_date, creator, checker from Sale_orders",
"SELECT ID, sale_order_id, product_id, Product_Name, product_catalog_id, model, Product_unit, Product_amount, product_ Price, Product_sum, memo from Sale_order_details ",
"SELECT ID, name, catalog, model, price, unit, memo, Createtime, State, code, PRODUCTNO from Products",
"SELECT ID, Name, memo from Product_catalogs"
};
Without XML mapping, but no way to know one-to-one or one-to-many or many-to-many relationship, so build a many-to-many relationship.
List l=sqlmapobjects (CONN,SQLS);
/*
Structure of L:
Sale_orders[]
|-----sale_order_details[] (sale_order_details.sale_order_id===>sale_orders.id)
|-----products[] (sale_order_details.product_id==>products.id)
|-----product_catalogs[] (sale_order_details.product_catalog_id==>product_catalogs.id)
*/

/*
With XML
*/
/*
Sale_orders Sales Order Form
Sale_order_details Sales Order Detail Table
Products List
Product_catalogs Commodity Category Table
From SQL, you can analyze
ID is the primary key
Sale_order_details.sale_order_id===>sale_orders.id
Sale_order_details.product_catalog_id==>product_catalogs.id
Sale_order_details.product_id==>products.id
*/
string []sqls=new string []{
"SELECT ID, Total_sum, Memo, State, Modify_date, creator, checker from Sale_orders",
"SELECT ID, sale_order_id, product_id, Product_Name, product_catalog_id, model, Product_unit, Product_amount, product_ Price, Product_sum, memo from Sale_order_details ",
"SELECT ID, name, catalog, model, price, unit, memo, Createtime, State, code, PRODUCTNO from Products",
"SELECT ID, Name, memo from Product_catalogs"
};

/*
<?xml version= "1.0"?>
<MapObject>
<!--a hibernate-like mapping, but it's easier to understand, and you can omit field mappings-->
<object tablename= "Sale_orders" class= "Org.test.pojo.SaleOrder" >
<onetomany tablename= "Sale_order_details" class= "Org.test.pojo.SaleOrderDetail" >
<!--primary fine table mapping-->
<ParentKey>id</ParentKey>
<ChildKey>id</ChildKey>
</OneToMany>
<!--field mappings are optional, generally the same or according to ROR rules-->
<FieldMap> Optional ...</fieldmap>
</Object>
<object tablename= "Sale_order_details" class= "Org.test.pojo.SaleOrderDetail" >
<!--additional Code table mapping 1 to 1 relationship-->
<onetoone tablename= "Products" class= "org.test.pojo.Product" >
<parentkey tablename= "Sale_order_details" >product_id</ParentKey>
<childkey tablename= "Products" >id</ChildKey>
</OneToMany>
<FieldMap> Optional ...</fieldmap>
</Object>
<object tablename= "Sale_order_details" class= "Org.test.pojo.SaleOrderDetail" >
<onetoone tablename= "Product_catalogs" class= "Org.test.pojo.ProductCatalog" >
<parentkey tablename= "Sale_order_details" >product_catalog_id</ParentKey>
<childkey tablename= "Product_catalogs" >id</ChildKey>
</OneToMany>
<FieldMap> Optional ...</fieldmap>
</Object>
<object tablename= "Product_catalogs" class= "Org.test.pojo.ProductCatalog" >
<FieldMap> Optional ...</fieldmap>
</Object>
</MapObject>
*/

String xml= "...";
With XML mappings
List l=sqlmapobjects (Conn,sqls,xml);
/*
Structure of L:
Sale_orders[]
|-----sale_order_details[] (sale_order_details.sale_order_id===>sale_orders.id)
|-----products[] (sale_order_details.product_id==>products.id)
|-----product_catalogs[] (sale_order_details.product_catalog_id==>product_catalogs.id)
*/
Of course, the class to be written well in advance, here is not detailed.

Save the problem is more serious, take out the SQL mapping can be well resolved, basically a function, a group of SQL, plus a little less XML can be expressed clearly, but this does not solve the problem of saving objects.

An imaginary Save API.

public void Saveobject (Connection conn, Object obj,string XML); Save a single object, simply extend the object to SQL, allow XML mappings, or do not map

public void Saveobjects (Connection conn, List Objs, String XML); To save an object tree to a database

The list or manual combination of the previous list can be saved with saveobjects, the task of this function is more heavy, because there is no state, so to judge the changes have been very troublesome.

One idea is to add attributes to the object, then to be maintained by the developer, such as whether the interface modification is likely to have a state bit, this state bit can be used, and then the function according to the status of the position to determine whether to update.

One idea is to learn from the class itself whether the object has been tampered with, like AOP, record it when it is modified, and then function to determine if it has changed, and then compose the SQL to update it.

As for the bulk modification is the strength, directly with SQL, learning SQL than HQL cost is lower, after all these years.

Considerations for peripheral Utilities: Basically, for SQL generation, or database function substitution

Public String generateinsertsql (DBType type,object obj);//Generate INSERT statement

Public String generateupdatesql (DBType type,object obj);//Generate UPDATE statement

Public String generateselectsql (DBType type,object obj);//Generate SELECT statement

Anyway, the idea of this function toolbox has these few:

1. Use functions instead of using environments to replace JDBC or application servers.

2. The use of mature SQL, rather than the creation of language, up to the increase in SQL preprocessor, some functions into database-related, simple text features.

3. Maintain compatibility with various environments. Objects are clean and, of course, AOP is hard to say that the object is not clean, but it should basically apply to all environments.

Disadvantage: Because there is no environment, save the object a little trouble, with SQL to solve the batch update and delete, if necessary, add several SQL statement generator. Saving the object tree is a big drawback, and there is no good way to keep the object tree intact and efficient, only the two less-than-perfect methods mentioned above, because the JVM has no reason to provide object state.

However, this use of functional methods to solve the problem of multiple inheritance is relatively clean and comfortable, can be dynamic, but also static, arbitrary, flexibility, efficiency and compatibility.