Home >Java >javaTutorial >How to write the javaweb business layer
Business layer
Service layer: Reference the corresponding Dao database operation, where you can write the code you need (such as simple judgment).
The service layer calls various DAO business operations. For example, if you have a business that is added and then modified. Then you call the add and modify operations of dao respectively, including some data conversion and logical judgment in the service layer, and dao is just adding, deleting, modifying and checking. And transactions are generally placed in the service layer.
The Service layer and the DAO layer may both operate on the database, and their specific differences are:
dao and service correspond to
Generally, Hibernate DAO only operates one POJO object, so one DAO corresponds to one POJO object. The Service layer is for transaction management (declarative transaction management) when processing 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 operations.
The presence or absence of Service
My opinion on this point may not be correct. There are two models in my mind for building the business layer:
Mode 1 is Service DAO, that is, DAO only performs CRUD and similar simple operations (called function points and does not include business logic). Service is combined into business logic by calling one or more function points in DAO. Service The quantity should be determined by the functional module.
In this model, the business logic is placed in the Service, and the boundaries of the transaction should also be controlled in the Service. Of course, controlling transactions directly in the Service will introduce non-business logic code. Fortunately, Spring's AOP can solve this Problem, this is also one of the reasons for the introduction of Spring.
If we talk about the shortcomings, it is that the operations on some objects are simple CRUD, and the Service layer seems cumbersome.
Mode 2 is Service BO, and BO = DAO business method, add business methods on the basis of the original DAO to form a BO object. It should be noted that business methods in BO are often targeted at one entity object. If they need to span multiple entity objects, the method should be placed in Service.
For example,
A simple bank account management system creates an account BO object, which can contain password changes. , withdraw money and other business methods (it is not difficult to see that these methods only operate on a single account object). Now we need to add a transfer method, which should be placed in Service.
What is the relationship between Service and BO here? Another example:
Take the national administrative agencies as an example: the Grain Bureau is responsible for collecting grain, selling seeds, etc., and the Ministry of Construction is responsible for approving land sales, building roads, etc. These are all matters within the administrative department. Son. Suddenly there is a flood in a certain place. During the disaster relief, the Grain Bureau needs to open a warehouse to release grain, and the Ministry of Construction builds temporary houses. How to coordinate the two departments? It is necessary to establish a special disaster relief committee, which will allocate resources from the two parts. The two parts here are BO, and the disaster relief committee is Service. I don’t know if I expressed my meaning accurately, haha. Mode 1 has clear boundaries when dividing Service and DAO, but it will bring some unnecessary code. The partitioning of Mode 2 is relatively complex, but it can improve coding efficiency.
Of course, in small-scale applications, it is acceptable to use DAO or BO without Service.
Whether there are interfaces between Service and DAO
The interface is a contract, which can have multiple implementations. Therefore, the presence or absence of interfaces depends on whether the specific implementation needs to be diversified. If it is determined that there is only one implementation of a DAO or a Service, then there is little meaning in abstracting the interface. However, some large applications may require multiple implementations of DAO and Service (such as the account DAO in the example above, which may require a Hibernate implementation, a CMP implementation and a JDO implementation). In order to hide the specific implementation class from the upper level, you need Use interfaces.
Hide the creation process of specific implementation classes. There are two methods: one is the practical factory method, which comes at the cost of a large amount of code (one factory for each DAO and Service). The second is to use Spring's IoC to implement dependency injection without writing additional code. This is also the second reason for introducing Spring.
The above is the detailed content of How to write the javaweb business layer. For more information, please follow other related articles on the PHP Chinese website!