7. O/R
Hibernate, EJB Entity Bean, JDO, and ibatis are popular o/R Mapping frameworks.
Some of my work involves complex optimized native SQL statements and a large number of batch complex logic processing. The existing o/R framework cannot meet the functional and performance requirements.
I made such a lightor framework and used some O/R row er and column mapper concepts described in Martin Fowler's enterprise architecture model.
The most typical usage is:
Resultset rs = ps.exe cutequery (a long complex native SQL );
// Will return a lot of records
A A = new ();
B = new B ();
Imapper amapper = mapperservice. getmapper (A. Class );
Imapper bmapper = mapperservice. getmapper (B. Class );
While (Rs. Next ()){
Amapper. populate (A, RS );
Bmapper. populate (B, RS );
Businesslogic (A, B );
}
As you can see, lightor does not need to put all records in an object list at once. It can be used as needed. In the whole process, A and B only have one copy, which greatly saves space and time, greatly improves development efficiency and reduces repeated code.
No other O/R can support this usage. Here, the populate method of the Mapper of lightor requires the resultset parameter. Generally, O/R containers do this. Do not say that they are resultset. Even connections are all packaged and cannot be viewed by you.
Lightor's design philosophy is to deal with both simplicity and complexity. The Mapper entity part of lightor automatically generates code. Similar to JDO's static enhance. The difference is that JDO static enhance directly modifies Bean class. Lightor does not move the original bean, but generates the corresponding mapper source/class. This method is most conducive to tracking and debugging. As for release and deployment, the situation is similar to that of JDO. It is not as good as Hibernate's dynamic code enhancement.
I envy the features of dynamic interpretation languages such as Python and Ruby, and don't need these troubles at all.
At this layer, I mainly focus on performance and cache policies, rather than simplicity. I think the bottleneck of an application system mainly exists in the O/R and DB layers. We should not simply sacrifice some possible optimizations to pursue the elegance of the OO structure or the convenience of programming.
I have several articles on lightor's cache policy on my blog.
Http://blog.csdn.net/buaawhl
Database Object Cache Policy
Http://blog.csdn.net/buaawhl/archive/2004/12/21/224184.aspx
Paging & querykey & fixed-length prefetch
Http://blog.csdn.net/buaawhl/archive/2005/01/08/245005.aspx
8. Summary
My ideal web development architecture is as follows:
Fast development, fast operation, clear and elegant structure.
Specific to each layer.
The Web framework layer mainly pursues fast development.
The o/R layer is mainly designed for fast operation.
The page resource layer and Page Template layer mainly aim for clear and elegant structure.