Next, let's talk about the three-tier architecture (passing parameters and returning values)

It is usually okay to use the layered idea to do things during design. However, if you are not familiar with the idea, the design architecture is often damaged unconsciously during coding, the encoding and design are inconsistent. For example, the question of passing parameters between layers (using an object or a simple data type) and the question of returning values from each layer (using an object or a datatable or dataset ). What should I pay attention to when binding a report.

The following issues (layer-3 as an example) are discussed. The core idea is that project development (coding) must comply with the project design.

PASS Parameters

If the three-tier architecture is used for the project, we must always focus onObject-oriented ThinkingAnd"Three-tier architecture" SystemTo encode, that is, to conform to the reference relationship between layers. It cannot damage its architecture (that is, it cannot damage the relationship between the layers of the design ).

The layer-3 architecture specifies that layer-3 communication is performed by passing model (entity) parameters. In this architecture, only the objects under the four packages (simple data types are encapsulated inside the objects) are visible, and nothing else exists, therefore, parameter transmission between layers must be completed through object. If a simple data type is used (to pass an attribute of an object class), the system of the three-tier architecture is damaged (the system does not exist ).

The transfer object conforms to the object-oriented encapsulation principle. The information is hidden in the class, which is easy to expand and maintain later.

Of course, if the design is not hierarchical, when passing parameters at ordinary times, passing objects has its own advantages and disadvantages as compared with general data types.

Return Value

In fact, it is the same problem as above. Previously, to facilitate binding to the control, the datatable or dateset will be returned at Layer D.

This not only violates the object-oriented idea, but also deviates from the three-tier architecture design idea.

First of all, in the same way as above, there are only four packages (ui, BLL, Dal, and model) in the layer-3 architecture (simple data types are encapsulated inside the object ), there is no other thing, so the layer and layer cannot communicate through datatable or dateset. In this case, both the B layer and the U layer will also use datatable or dateset, that is to say, the B and U layers are directly related to the database. These all deviate from the three-tier architecture design philosophy.

Second, if the datatable or dateset is returned, the model layer is useless. This is what the entity should do. The correct method should be to encapsulate the returned content in the object, and then return the object to implement communication between layers.

Report binding

When using reports, we are used to directly bind database tables to vs reports. In this case, we must provide design instructions because this does not conform to the three layers we designed above. Instead, the U layer is used for direct interaction with the database, which can be explained separately as follows:

 

Summary: The idea of hierarchy strongly requires object-oriented. If a project is mostly suitable for a specific design (for example, the three layers above), a small part uses another design (for example: the above report binding) is better, you can use these two designs at the same time, but you must give a description of the design that is used in that small part. That is, under any circumstances, project development (coding) must comply with the project design.