Sequence of calls Service,action,jsp,formbeam,dao in the SSH framework

This article from: http://blog.csdn.net/w_basketboy24/article/details/8642846

JSP initiates the request. Actionform encapsulates the request parameters. The action accepts the request and accepts the encapsulated Actionfromaction call service. After the service has been processed by the business logic, it then calls DAO (or implements CRUD operations on the data directly in the service) DAO to crud the database. 1,dao and service correspondence

In general, Hibernate DAO operates on only one Pojo (Simple Java object, which is actually a normal JavaBeans) object, so a DAO corresponds to a Pojo object. The service layer is for transaction management (declarative transaction management) when it is processed to contain multiple Pojo objects (that is, data operations on multiple tables). The service layer (the implementation class of its interface) is injected with multiple DAO objects to complete its data operation.

2, the service is not

My view is not necessarily correct, my mind now has two modes of building the business layer:

Mode 1 is Service + DAO, which is only crud and similar simple operations in DAO (called function points, does not contain business logic), and service is combined into business logic by invoking a function point in one or more DAO. The number of services should be determined by the function module.

In this model the business logic is placed in the service, and the boundary of the transaction should also be controlled in the service. Of course, controlling transactions directly in the service introduces code that is not business logic, but fortunately spring's AOP solves this problem, which is one of the reasons to introduce spring.

When it comes to shortcomings, it is that the manipulation of certain objects is simply a crud,service layer that seems cumbersome. Mode 2 is Service + bo, and Bo = DAO + Business method, on the basis of the original DAO added business methods to form Bo objects. It is important to note that the business method in Bo is often targeted at an entity object, and if it needs to span multiple entity objects, the method should be placed in the service.

For example, a simple bank account management system, create an account of this Bo object, there can be changed password, take money and other business methods (it is not difficult to see, these methods are only for a single Account object operation). Now you need to add a transfer method that should be placed in the service.

What is the relationship between service and Bo here? Another example: take the national administrative organs as an example: the Food Bureau is responsible for collecting grain, selling seeds, etc., the Ministry of Construction is responsible for approving land transactions, construction of highways, etc., which are part of the administrative parts of the affair. Suddenly there was a flood, the relief of the need for food bureau to open a warehouse, construction of temporary housing, how to coordinate the two departments? It is necessary to set up a special disaster relief Committee, to be allocated by the Disaster Relief Committee in the face of two-part resources. Here are two parts of Bo, and the Disaster Relief Committee is the service. I do not know whether the expression is accurate, hehe. Pattern 1 has clear boundaries when dividing service and DAO, but it brings some unnecessary code.

The partitioning of pattern 2 is relatively complex, but it can improve coding efficiency.

Of course, small-scale applications, without service, are entirely DAO or bo is acceptable.

The interface of 3,service and DAO is not

An interface is a contract that can have multiple implementations. So whether or not the interface depends on the specific implementation needs diversification. If there is only one implementation of a DAO or a service, then the abstraction of the interface is of little significance. However, some large applications may require a variety of DAO and service implementations (such as the account DAO in the example above, which may require a hibernate implementation, a CMP implementation, and a JDO implementation), and an interface is required in order to hide the concrete implementation class from the top layer.

There are two ways to hide the creation of a concrete implementation class: The first is a utility factory approach, at the expense of a large code size (one factory per DAO and service). The second is to use the spring IOC to implement dependency injection, without the need to write extra code, which is the second reason to introduce spring.

DAO Layer: DAO layer is mainly to do the work of data persistence layer, is responsible for contact with the database of some tasks are encapsulated here, the DAO layer design first is to design the DAO interface, and then define the implementation class of this interface in the spring configuration file, then you can call this interface in the module for Data service processing , instead of worrying about which class the specific implementation class of this interface is, the structure is very clear, the data source configuration for the DAO layer, and the parameters about the database connection are configured in spring's configuration file.

Service layer: The service layer is responsible for the logic application design of the business module. The same is to first design the interface, then design its implementation of the class, and then the spring configuration file to configure its implementation of the association. This allows us to invoke the service interface in the application for business processing. Service layer of the business implementation, specifically to call to the defined DAO layer interface, encapsulating the service layer of business logic to facilitate the independence of general business logic and reuse, the program appears very concise.

Controller layer: Controller layer is responsible for the specific business module process Control, in this layer to invoke the Serice layer interface to control the business process, the configuration of the control is also in the spring configuration file, for the specific business process, there will be different controllers, In our specific design process, we can abstract the process, design a reusable sub-unit process module, which not only makes the program structure clear, but also greatly reduces the amount of code.

This layer of view layer is closely related to the control layer and needs to be combined to work together. The view layer is primarily responsible for the presentation of the foreground JSP page,

DAO layer, service layer these two levels can be developed independently, mutual coupling degree is very low, can completely independent, such a pattern in the process of developing large projects, especially has the advantage, Controller,view layer because of high coupling degree, so to combine to develop together, But it can also be seen as a whole that is developed independently of the first two layers. In this way, before the layer and layer we just need to know the definition of the interface, call the interface to complete the required logic unit application, everything seems very clear and simple.

The overall planning of DAO design requires a one by one correspondence between the design table, and the implementation class.

DAO layer defines the interface in the same way, this is by the DAO layer on the database access to the operation of the decision, the operation of the database, we basically need to use is new, update, delete, query and other methods. Therefore, the DAO layer should basically cover the corresponding operation of these methods. In addition, you can define some custom special methods for accessing the database.

Service Logic Layer Design

The service layer is built on the DAO layer, and the service layer can be established after the DAO layer is established, and the service layer is under the controller layer, so the service layer should call the interface of the DAO layer. It also provides the interface to the controller layer's class to make the call, which is just in the middle of an intermediate position. Each model has a service interface, each of which encapsulates its own business processing methods.

Some of the methods defined in the DAO layer are not used at the service layer, so why do you define it in the DAO layer? This is determined by the logic of the requirements we define. DAO layer Operations After abstraction is basically universal, so we can define the DAO layer when the relevant method is defined, the advantage is that the service is extended without the need to modify the DAO layer, improve the program extensibility.

Sequence of calls Service,action,jsp,formbeam,dao in the SSH framework