Three layers structure: data access layer, business logic layer, interface layer
- The data access layer, the DAO, operates on the database.
- Business logic layer is also called domain layer and component layer. Operations for specific problems can be understood as DAO layer operations and data business logic processing.
- The interface layer is also called the presentation layer. The presentation layer can be invoked to provide services regardless of how the presentation layer changes, provided that the logical layer is complete.
There is a logical layer between the client and the database.
The difference between three-tier architecture and MVC
MVC (Model- View- Controller) is a common architectural pattern that can be used to create a distinction between domain objects and UI presentation layer objects.
At the same architectural level, they both have a presentation layer (View), but differ in the other two layers. The most significant difference is that the concept of Controller is not defined in the three-tier architecture. MVC also does not treat logical business access as two layers, which is the main difference between using a three-tier architecture or an MVC builder.
A five-tier structure is commonly used in Java development
Servlet, Service, Modle, Dao, Util, in addition to the commonly used five layers of development, Util, is essentially an extension of the previous three layers, but with the addition of a physical layer and a tool layer.
The Servlet layer is used to receive requests and invoke the corresponding service layer to process the request. It is the closest Java layer to the browser, namely the presentation layer.
The Service layer mainly writes the specific business logic. Each Service generally contains a set of related business logic (for example, user management is a Service, article management is a Service), namely the business layer.
Modle/Entity layer (collectively referred to as model layer) is the entity class of the corresponding database table. Generally, each model layer class corresponds to a database “table”. Generally, it is used for ORM object relational mapping.
Dao layer is generally used for the specific operation of the database, including various specific additions, delesions, changes and query statements and the mapping between the database data and the Java model. The data access layer.
The Util layer is mainly used for functions (classes) that do not belong to a specific layer and occur frequently, such as connecting to a database, obtaining system parameters, and exporting Excel sheets.
A more complex hierarchical structure
As the number of users of the website continues to improve, the system architecture is also constantly adjusted. Sometimes, as the business gets more complex, the three-tier architecture just doesn’t seem to be enough. For example, in addition to providing page access for users, our application needs to provide some open interface for external system calls. This interface does not belong to the interface layer, nor should it belong to the business logic layer, because it may also contain some processing unrelated to the business logic, such as permission control, flow control, etc.
Also, with the proliferation of microservices, we may have to rely on many external interfaces or third-party platforms in our applications. This part of the code does not fit into either the business logic layer or the data access layer.
So, gradually, on top of the three-tier architecture, the hierarchy of the system architecture becomes more complex. It is precisely because of the complexity, it is a test of the ability to design the architecture, because the hierarchy is not good, it is likely to affect the development behind, to bring great difficulties in code maintenance.
Below is the application layered structure advocated by Alibaba (refer to Alibaba Java Development Manual) :
Open interface layer
Encapsulate Service methods directly and expose them as RPC interfaces. Through Web encapsulation into HTTP interface; Performs gateway security control and traffic control.
Terminal display layer
Each side of the template renders and executes the displayed layer. Currently, velocity rendering, JS rendering, JSP rendering, mobile display and so on.
The Web tier
It mainly forwards access control, verifies all kinds of basic parameters, or handles simple services that do not reuse.
The Service layer
Relatively specific business logic services layer.
The Manager layer
General business processing layer, it has the following characteristics: 1) the third party platform encapsulation layer, preprocessing returned results and transform abnormal information; 2) Subtraction of the general capabilities of the Service layer, such as caching schemes and middleware general processing; 3) Interact with the DAO layer and reuse the combination of multiple DAOs.
DAO layer
Data access layer that interacts with low-level MySQL, Oracle, and Hbase.
External interface or third-party platform
Including RPC open interfaces from other departments, basic platforms, and HTTP interfaces from other companies.
Transaction processing
With that layer in mind, let’s take a look at one of the most common concerns when writing Java Web code: which layer of control should be used for transactions when database operations are involved?
Different people have different opinions on this question. The author thinks that transaction processing should be placed in Service layer and Manager layer.
There should be no transactions in the DAO layer, and it should be pure CRUD and other generic data access methods. A DAO should handle only its own operations and not any combination of them. The combination of things to the top.
The Service layer and Manager layer typically combine multiple DAO CRUD operations, such as: When registering a User requires INSERT logging in the Log table, construct a transaction in the Service layer and call user.insert () and log.insert () in the Dao layer.
Exception handling
Exception handling is one of the most important topics in Java. Effective Java has many best practices for handling exceptions. Instead of going into the details, this article will simply explain how exceptions should be handled between layers of application code, whether they should be caught themselves or thrown up one layer.
First, exceptions are possible at each level. Because the responsibilities of each layer are different, the approach may be different.
DAO layer
In the DAO layer, there are many types of exceptions that can be generated, whether they are SQL related or database connection related.
This layer can be handled simply by try-catch (Exception) and wrapping it as a DAOException and throwing it to the previous layer. This layer usually does not need to print the log, leaving it to the Service or Manager layer to print.
Try {CRUD}catch (Exception e) {throw new DAOException (e); }
Manager/Service
First, exceptions thrown by the DAO layer must be caught and logged to print on site.
But it is worth noting that if it is need transaction control methods, attention should be paid to catch exceptions to cast up again after a new exception, such as TransactionRolledbackException, otherwise the transaction cannot be rolled back.
Exceptions that occur at these two levels can be thrown up or handled on their own depending on the situation. If it is an exception that you can handle, you catch it, log it, and return it to the previous level through ErrorCode, etc. If it’s an exception that you can’t handle or don’t know how to handle, you throw it to the next level.
Web
First of all, it should be clear that exceptions should not be thrown from the Web layer, because if thrown from this layer, the user may be redirected to an unfriendly error page or even an error message.
If you realize that this exception will cause the page to fail to render properly, you should jump straight to a friendly error page with an error message that is easy for the user to understand.
Open interface layer
This layer, like the Web layer, cannot throw exceptions. This is typically fed back to the external caller through ErrorCode and ErrorMessage. In this layer, you should handle all the exceptions by yourself, define the ErrorCode, and record the log to facilitate troubleshooting in the future.
References:
Blog.csdn.net/cx776474961…