Database-related: performance Layer Control that complies with oo conventions

The reference Sub-title of Hibernate is: O/R persistence in line with java conventions, which reveals the major issue of the current three-tier structure, that is, the inconsistency of the three-tier structure. So far, it is still difficult to implement "master-detail" and "lookup" quick user interaction in the C/S mode on the web interface.

The current common web application structure, including web browser/application server/database. The mainstream database model is still the classic E/R model, which is based on the row set. Therefore, in the practices of vb/delphi/power builder, data source/table set is based on the row set, and odbc/jdbc driver is also based on the row set. The DbGrid at the view layer is also based on the row set, which corresponds very well to the Entity model and is easy to develop and intuitive. I believe this is one of the key reasons for the rapid promotion of the C/S model. Both "master-detail" and "lookup" are extremely common and intuitive Association modes in C/S mode.

But in essence, Object pascal/java is object-oriented. Here, there is a major inconsistency: OO vs E-R. The solution is the EJB and O/R mapping tools. The entity bean of EJB is an early entity encapsulation form. However, compared with the advanced tools (persistence of POJO execution) represented by hibernate, OO and ER are cumbersome and difficult to use. Among these tools, the most essential function that represents the integration of OO and E-R is to inherit the correspondence between the tree and the table structure. Hibernate2 supports two basic mappings between the entire inheritance tree and a table, and between each class and a table in the inheritance tree. The join tag introduced by hibernate 3 can better combine the two, each class can be used to save part of the persistent data in the same table or in the new table as the base class. It can be said that hibernate 3 has completed this corresponding task very well. "Master-detail" and "lookup" are associated with "one-region" and "one-one" in the ing file such as hbm. xml.

After the database and java are integrated, the next step is inevitably the integration of the existing web client and server code. On the surface, most web clients use html/javascript, while the server uses java for output. The two are simple command/Feedback models, after this model has evolved from model 1 to the MVC model, coding becomes clearer, but developers still find that writing web apps is still not a simple task. Struts/webwork is still a very underlying foundation, and it does not help to write client business objects. For example, when modeling a server-side java program, you are used to using pojo to analyze orders, customers, and products. However, when compiling a web client, struts/webwork can only help you complete the Page Submission/feedback process, but cannot help you analyze the client business: After the customer is selected when the order is created, determine whether the customer has sufficient prepayment. Such a simple case reflects the input tag of each field in the programmer's mind and the model posted on each page, and how to use action processing to re-render the next page.

The biggest problem is that the web client code as the presentation layer is out of line with the semantics of the server code. The specific performance is as follows:
When using the MVC structure such as struts/webwork, you usually do not consider business control on the client. For example, you can determine whether the pre-payment is sufficient by using javascipt. Therefore, you must refresh the page several times to complete the entire logic.

To solve this problem, you can usually transfer the business logic to the client, use javascript + xmlhttp or javascript + web service, java applet/application, or even use the office Platform (embed code into excel) complete the entire business logic. There are also many problems:

1. To implement business logic on the client, the client code may not have any infrastructure such as Pojo. Javascript lacks basic structures such as interfaces. The excel solution is more difficult to implement at this point, because there are too many languages involved in the development, which makes development more difficult and project control difficult.
The direct consequence is that it is difficult to define associations such as "master-detail" and "lookup" in the client code. Even if pojo (plain old javascript object) and Its Association are defined in javascript in the Project Plan, it is difficult to use a ready-to-use association description such as hbm. xml.

2. It is difficult for the client infrastructure to bind interface elements. When processing a large amount of data, the excel solution demonstrates outstanding advantages. The customer has a high degree of acceptance of the excel program, however, the disadvantage is that such excel programs are difficult to achieve the dynamic query and other features that xmlhttp can easily achieve.

3. It is difficult for the client infrastructure to interact with the server. Xmlhttp and web services are optional. However, low efficiency in enterprise applications may cause server pressure risks and reduce performance and throughput. If excel is used, it also faces the challenge of interacting with server data. Both xmlhttp and application solutions are faced with the requirement to abandon struts/webwork to implement request/response dispatch again.

4. It is difficult for the client infrastructure to perform unit tests. There are junit4js and port junit 3.8.1, but there is no mature stub/mock tool. The excel solution cannot be tested here.

5. The client infrastructure is difficult to debug. Javascript lacks log tools like log4j (log4jsHttp://www.petrusrex.com/Programmes/jslib.htmSuch tools are far from mature), and it is difficult to perform breakpoint tracking. The excel solution has a complete vba environment.

6. Low client infrastructure operation efficiency. Javascipt/vba are both interpreted languages, and it is difficult to implement complex logic. The performance of javascipt depends on their fine-grained interface control.

7. Due to the split of browsers, the language is not standard and applications are difficult to use across platforms. On the IE platform, you can use the behavior and expression types of AOP operations, but they cannot be implemented in mozilla.

The jsf solution is expected to be an alternative, but according to the current situation of myfaces, more presentation layer controls must be implemented to achieve more complex and flexible control.

The following is a breakthrough in the software development method. Looking forward, there may be a breakthrough in the design method. MDA is the direction; the other is the breakthrough in implementation, in specific technologies like webapp (except webapp, application also faces similar problems), whether model definitions can be directly brought into the presentation layer, JSF and. NET may have a new round of competition