Struts advantages and disadvantages (2)

According to the trajectory of human development, the first article is analysis and summary. The second article is about innovation and prospects.

The Struts Framework places the center on the Web server. There are two possibilities for business processing:

1) The web server has further backend Service Processing servers. Remote Object Access technology may be used. What the Web server does is serialize the parameters passed from the browser query string into objects that the Business Server can understand.

2) The web server does not have a further service processing server, or the business layer does not exist. The Web server can directly operate the database.

In the second case, there was no business layer, and it was born to be consistent with my claim.

Analysis of the first case:

In actual development, the business processing method is not in line with the database I advocate. The business we are considering is not a stored procedure, but a Java/. Net/COM/corbra class.

Now we assume it is a Java class. When we re-use. Net to develop the surface layer, the service is not a database, and the OOP class at this layer cannot be discarded. Although most of the burden on the business layer is insignificant, permissions are usually placed on this layer, and it is not enough.

Considering that Java is not needed, you can use. Net to re-develop a business layer. It is easy for Java to avoid any issues, and subsequent maintenance will also be quite troublesome.

Another feasible method is to use WebService technology to achieve intercommunication between Java objects and. Net object objects. However, this technology is too difficult to implement. It is not as effective as the database I advocate. Database is the first practice, which puts businesses on database servers, securely avoiding the development platform's melee winter. This section has been analyzed in the database.

Therefore, when we focus on the business layer, we find that the business layer should not exist in the form of OOP, but store it in the database as a stored procedure. The PO ing made by struts is not as significant as you think.

The reason is that the stored procedure is a procedural code snippet, and its interface is also procedural rather than object-oriented language style, and does not have the physiological desire to understand the incoming objects.

In this way, the picture I imagined is like query. jsp? Param1 = value1 & param2 = value2 and other query parameters are delivered to stored procedures such as query (param1, param2.

Review why the database resolves the object-oriented language:

1) because the attribute values of objects are stored in the database, the database has the ability to query the attributes of objects -- otherwise, we will talk about object storage. Since the object is already stored in the database, the database language naturally has the permission to read and write attributes.

2) The object-oriented platform is in battle, and the current situation is unstable. It is better to hide in the database for security.

Now let's think about the objects that have taken refuge in the data warehouse.

Without the support of the OOP language, we can only think with OO's head. This seems to overwrite vitegenstein's statement about language as the limit of thinking. :)

In a database, a type of table contains one row and one object. Inherits the Shared primary key. These principles are undoubtedly a golden law for serialized objects.

Now consider the method.

Class method is easy to handle. For example, the company class, which is similar to the Company. Create (para) static method, is [row] company_create (para), used to create a company.

Considerations when Inheritance occurs. For example, for a supermarket company or a supermarket company, the method should be

[Row] supermarket_create (para, para)

Begin

Company_create (para );

-- Create supermarket add-Info

End;

Add transaction considerations in actual use. It seems to be easy.

Polymorphism. Because the SQL language supports executing SQL scripts, you can use exec '... {table name}...' to simulate polymorphism. This is similar to the later binding of reflection implementation.

Some of SQL's own language features are beyond the reach of object-oriented languages. For example, a data row formed by a multi-Table query may be an anonymous class temporarily created. Hash Tables can be imitated, but they are not the type in OOP, and cannot be inherited.

The above is a reflection on the Po ing of struts. If you move the focus to the Service server on a specific platform, it is good to use PO ing.