Shulou(Shulou.com)06/02 Report--

This article mainly shows you the "java development MVC three-tier architecture plus a layer of Manager layer principle example analysis", the content is easy to understand, clear, hope to help you solve your doubts, the following let the editor lead you to study and learn "java development MVC three-tier architecture plus a layer of Manager layer principle example analysis" this article.

MVC three-tier architecture

When we first became programmers, we were "taught" by our predecessors that the design of the system should follow the MVC (Model-View-Controller) architecture. It divides the whole system into three levels: Model (model), View (view) and Controller (controller), that is, the user view is separated from the business processing, and connected by the controller, which well realizes the decoupling of performance and logic, and is a standard software hierarchical architecture.

The MVC hierarchical architecture is the simplest form of layering on the architecture. In order to follow this hierarchical architecture, we tend to build three directories when building a project: controller, service, and dao, which correspond to the presentation layer, the logic layer, and the data access layer, respectively.

The functions of each layer are as follows:

Controller layer: mainly to forward access control, check all kinds of basic parameters, or simply deal with services that are not reused.

Service layer: mainly deals with business logic and transactions

Dao layer: responsible for data exchange with underlying database MySQL,Oracle, etc.

But as our business logic becomes more complex and more code is written, the problem of this simple three-tier architecture becomes more and more obvious.

MVC architecture drawbacks

There are several obvious problems with traditional MVC layering:

The code of Service layer is bloated.

Large transactions are easy to occur in the Service layer, and transactions are nested, resulting in a lot of problems and extremely difficult to troubleshoot

Dao layer miscellaneous business logic

Dao layer sql statements are complex, and there are many related queries.

In order to solve this problem, we refer to the alibaba java Development Manual and create a general business processing layer (Manager layer) under the Service layer.

The Manager layer is mainly added to this hierarchical architecture. The relationship between the Manager layer and the Service layer is that the Manager layer provides atomic service interfaces, and the Service layer is responsible for arranging atomic interfaces according to business logic.

Characteristics of Manager layer

The alibaba java layer is described in the Manager Development Manual as follows:

Manager layer: general business processing layer, which has the following characteristics:

For the layer encapsulated by the third-party platform, the preprocessing returns the results and transforms the abnormal information, adapts to the upper layer interface, sinks the general capabilities of the Service layer, such as cache scheme and general processing of middleware, interacts with the DAO layer, and reuses multiple DAO.

In actual development, we can use the Manager layer like this

For complex business, service provides data to the Manager layer, is responsible for business orchestration, and then sinks the transaction to the Manager layer. The Manager layer does not allow mutual calls and transaction nesting does not occur.

Focusing on the sql language without business, it is also possible to encapsulate the general business in the dao layer at the manager layer.

Avoid complex join queries, the database pressure is much greater than java, so it is necessary to strictly control the sql, so you can split at the manager layer, such as complex queries.

Of course, for simple businesses, you don't have to use the Manager layer.

Manager layer use case

Let's give an example to illustrate the usage scenario of the Manager layer:

Suppose you have a user system that has an interface to get user information, which calls the getUser method of the logical Service layer, and the getUser method interacts with User DB to get data. The left side of the figure below shows the part.

At this point, the product puts forward a requirement that when displaying user information in APP, if the user does not exist, then automatically create a user for the user. At the same time, to be a HTML5 page, the HTML5 page retains the previous logic, that is, there is no need to create a user.

At this time, according to the traditional three-tier architecture, the boundary of the logic layer becomes unclear, and the presentation layer also undertakes part of the business logic, because we often add business logic processing to the presentation layer Controller to orchestrate the acquisition of users and the creation of user interfaces.

After adding the Manager layer, the Manager layer provides the interface to create and obtain user information, while the Service layer is responsible for assembling the two interfaces. In this way, the business logic originally scattered in the presentation layer is unified to the Service layer, and the boundary of each layer is very clear.

Next, let's take a look at a piece of actual code that illustrates how the Service layer distinguishes from the Manager layer.

@ Transactional (rollbackFor = Throwable.class) public Result upOrDown (Long departmentId, Long swapId) {/ / verify 1 DepartmentEntity departmentEntity = departmentDao.selectById (departmentId); if (departmentEntity = = null) {return Result.error ("departmental xxx does not exist");} / verify 2 DepartmentEntity swapEntity = departmentDao.selectById (swapId); if (swapEntity = = null) {return Result.error ("departmental xxx does not exist");} / / verify 3 Long count = employeeDao.countByDepartmentId (departmentId) If (count! = null & & count > 0) {return Result.error ("employee does not exist");} / / operate database 4 Long departmentSort = departmentEntity.getSort (); departmentEntity.setSort (swapEntity.getSort ()); departmentDao.updateById (departmentEntity); swapEntity.setSort (departmentSort); departmentDao.updateById (swapEntity); return Result.OK ("success");}

The above code is often encountered when we adopt a three-tier architecture, so what's wrong with it?

The above code is a typical long transaction problem (similarly, calling a third-party interface). The first three steps use connection for verification, but because of the @ Transactional annotation on the method, the same connection is used for all three verifications.

For complex business and complex verification logic, the whole verification process will always occupy the connection connection, which may take a long time, and the connection will not be returned to the database connection pool until the end of the method.

For the unpredictable situation of complex business, it is not good to occupy the same connection connection for a long time, and the occupancy time should be shortened as much as possible.

Note: for @ Transactional annotation, when spring encounters this annotation, it will automatically obtain the connection from the database connection pool, open the transaction and bind it to ThreadLocal. If the business does not enter the final operation of the database, it is not necessary to obtain the connection and open the transaction. Instead, connection should be returned directly to the database connection pool for other use.

So after we add the Manager layer, we can write:

DepartmentService.java public Result upOrDown (Long departmentId, Long swapId) {/ / verify 1 DepartmentEntity departmentEntity = departmentDao.selectById (departmentId); if (departmentEntity = = null) {return Result.error ("departmental xxx does not exist");} / / verify 2 DepartmentEntity swapEntity = departmentDao.selectById (swapId); if (swapEntity = = null) {return Result.error ("departmental xxx does not exist");} / / Verification 3 Long count = employeeDao.countByDepartmentId (departmentId) If (count! = null & & count > 0) {return Result.error ("employee does not exist");} / / operate database 4 departmentManager.upOrDown (departmentSort,swapEntity); return Result.OK ("success");} DepartmentManager.java @ Transactional (rollbackFor = Throwable.class) public void upOrDown (DepartmentEntity departmentEntity, DepartmentEntity swapEntity) {Long departmentSort = departmentEntity.getSort (); departmentEntity.setSort (swapEntity.getSort ()); departmentDao.updateById (departmentEntity); swapEntity.setSort (departmentSort) DepartmentDao.updateById (swapEntity);}

The data is prepared in the service layer and then passed to the manager layer, where the manager layer adds @ Transactional transaction annotations for database operations.

The above is all the contents of the article "java Development MVC three-tier Architecture plus a layer of Manager layer principle". Thank you for reading! I believe we all have a certain understanding, hope to share the content to help you, if you want to learn more knowledge, welcome to follow the industry information channel!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.