Introduction to the business logic layer
The section of the thick black border of is the business logic layer, which can contain the following content:
- Application facade application appearance. This optional component provides a simple interface for the business logic component. Generally, multiple business operations are combined into one operation, making the business logic layer easier to use. This reduces dependencies because external callers do not need to know the Implementation Details of business logic formation and their relationships.
- Business logic component. In any application, the definition of business logic is concentrated in obtaining data, processing data, transmitting data, managing application data, business rules and policies, and ensuring data consistency and legitimacy. To maximize reuse, business logic components should not include any behavior. Business Logic creation can be divided into the following two directories.
- Business workflow component. After the UI collects the required data from the user and passes it to the business logic layer, the application uses the data to implement business functions.
- Business Entity component. Business entities, also called Business Objects, represent elements of the real world, such as customers and orders. Store Data and expose attributes.
General Design Considerations
- When designing the business logic layer, the software architecture goal has been minimized by separating different tasks into different focus fields. For example, it represents the logic, business workflow, and business entity for processing business rules in different focus fields. In each field, the design of components should be concentrated in this field, and relevant code in other fields should not be included. You can refer to the following principles:
- Determine whether you need an independent business logic layer. Using an independent business logic layer is a good idea to improve the maintainability of applications. The exception is that there is no other business logic except data verification.
- Determine the responsibilities and consumers of the business logic layer. It helps you decide what the business logic layer must do and how to expose the business logic layer. The business logic layer is used to process complex businesses, transmit data, apply policies, and verify data. If your business logic layer may be used by external applications, consider exposing the business logic layer as a service.
- Do not mix other components in the business logic layer. Avoid placing the presentation layer and data access layer code on the business logic layer. Decoupling the business logic from the presentation layer and data access layer can simplify the test of the business logic. The business logic layer enables centralized management of business logic to provide reusability.
- When accessing a remote business logic layer, reduce the number of requests. If the business logic layer is deployed on an independent physical layer, consider message-based Remote Application facade or service layer, and combine fine-grained operations into coarse-grained operations, for example: data transfer objects (DTO ).
- Avoid tight coupling between layers. Abstract is used to minimize coupling when creating interfaces for the business logic layer. Abstract technologies include the use of common object interfaces, general interface definitions, abstract base classes, and messages. For Web applications, message-based interfaces are used between the presentation layer and the business logic layer.
Specific design issues
There are always some common problems in the process of development and design. These problems can be divided into different areas in the design. The following lists some common fields;
- Authentication User Authentication
- Authorization User authorization
- Caching Cache
- Coupling and cohesion coupling and cohesion
- Exception management
- Logging, auditing, and instrumentation log, audit, performance Meter
- Validation Data Verification
User verification
- For application security and reliability, it is very important to design an effective user verification policy. If verification fails, your application will be vulnerable to spoofing attacks, Dictionary attacks, session hijacking, and various types of attacks. When designing a user verification policy, you can refer to the following principles:
- Do not authenticate users at the business logic layer unless they are within a trusted boundary and are used only at the performance layer or service layer of the physical layer.
- If your business logic layer needs to be used by multiple applications, use independent user storage to implement SSO. Avoid designing custom verification technologies. On the contrary, use the platform's built-in technologies at any time.
- If the presentation layer and business logic layer are deployed on the same machine, you must access the user's original ACL permission and consider implementing impersonation. If the presentation layer and business logic layer are deployed on separate machines, and you must access the user's original ACL permissions, consider implementing proxy.
Authorization
Designing effective authorization is very important for security and reliability. If authorization fails, information leakage and data destruction may occur. Refer to the following design principles:
- Use identity-based authentication to protect resources. Account group, role, and other context information.
- Consider role-based authorization.
- Do not mix the authorization code in the business processing code.
- In applications, authorization is everywhere. Ensure that the authorized infrastructure does not affect performance.
Cache
Caching is very important for improving performance and responsiveness. Use the cache to optimize data query, so as to avoid network reciprocating and repeated processing. As part of the cache policy, you must consider when and how to load data into the cache. To avoid client latency, use batch processing to asynchronously load data. You can refer to the following principles:
- Consider caching static data in the business logic layer with regular reuse to avoid caching data that is prone to changes. Consider caching data that cannot be obtained quickly and efficiently from the database to avoid caching a large amount of data. The minimum cache requirement is required.
- Consider formatting cached data into a format that can be used by the business logic layer.
- Avoid caching sensitive data or design protection methods for cached sensitive data.
- Consider the impact of Web server farm deployment on the cache solution. If any service in the server farm can process user requests, you need your cache solution to support data synchronization between services.
Coupling and cohesion
When designing components for the business logic layer, ensure the high cohesion of components to implement loose coupling between layers. It can help improve application scalability. You can refer to the following principles:
- Avoid circular references. The business logic layer should only know the following data access layer, and should not know the above performance layer or directly access other applications in the logic layer.
- Use abstraction to implement loose interfaces. Dependent on abstraction and implementation.
- Design tight coupling for the business logic layer unless dynamic behavior requires loose coupling.
- Design high cohesion. Components should only include components that implement specific functions. Avoid hybrid data access logic at the business logic layer.
- Design a message-based interface to expose the business logic layer and reduce coupling. If necessary, it can be deployed on an independent physical layer.
Exception management
- Only internal exceptions that you can handle are captured. Do not use exceptions to control business logic or application processes.
- Design appropriate Exception Propagation policies.
- Design exception logs, record key information, help locate errors, and do not expose sensitive information.
Log, audit, dashboard
Refer to the following principles:
- Centralized log management, auditing, and dashboards at the business logic layer.
- Do not include sensitive information in logs.
- Make sure that log failure does not affect the functions of the business logic layer.
- Consider using audit and logging to record all access behavior at the business logic layer.
Data Verification
Consider the following principles:
- Verify all input parameters and method parameters at the business logic layer, even if verification already exists at the presentation layer.
- Centralized verification methods to maximize testability and reusability.
- Restrict and reject user input. In other words, assume that all user input is untrusted. Verify the length, range, format, and type of the input.
