Hierarchy in Software System Architecture

Hierarchy in Software System Architecture

About the layered structure

As we all know, the classic three-tier structure includes the data access layer, business logic layer, and presentation layer. Of course, if you continue to expand, it can also be divided into four layers, five layers ......

I believe that many people have used it and many people have written it. But why is it so difficult for some people to make it clear? This is not my guess, instead, I met a lot of messy hierarchies that wanted to be layered but divided.

1. Data access layer:

Function Description: Processes interactions with databases and does not process data in any business. Capture Database interactive exceptions, and throw or record them.

Note: its role is Data Access. If you do not use any other ORM-like framework, it should be a collection of SQL statements (or you can write SQL statements in the stored procedure ), the business logic layer and the presentation layer must not contain SQL statements (including SQL keywords, single quotes, percent signs, and like ). So how to combine dynamic SQL statements? This should be the biggest problem. I have seen many systems define quite a few type parameters at the business logic layer, collect parameter data in the presentation layer, import the parameter data to the business logic layer, splice the SQL statements, and finally import the data access layer for operations, the concept of hierarchy is completely meaningless. How can this problem be solved? The earliest strong-type datasets, custom business entities, LINQ, or ORM can all be solved. Of course, this is only part of their functions (in fact, I don't want to use hql or LINQ similar to nhib.pdf)

2. Data Interface Layer:

Function Description: Provides interface standards for the data access layer to facilitate multi-database support, that is, database migration at will.

Here I want to mention the data interface layer. I have seen many project teams add a data interface layer on the data access layer, and the data access layer is the specific implementation of each data interface layer, however, when the business logic layer instantiates the data layer, it is still instantiated to a specific class object.

Idal_myclass dalmyclass = new dal_sqlclass ();

I don't know why, except for increasing the workload, it doesn't mean anything else.

So do you need such a data interface layer? I think the data interface layer is required when creating a system that supports multiple databases (for example, a CRM system that supports SQL Server and Oracle and MySQL, of course, a single data interface layer cannot complete this task. You also need to create their own data access layer for each database and use the factory mode and dependency injection (such as castle) the technology enables multi-database support. You can migrate data between databases during product installation or running.

3. Business logic layer:

Function Description: receives data transmitted from the presentation layer, performs business data verification, implements business processes, and finally transmits processed data to the data access layer.

You can think that there are two walls between the three layers, and no one can see them between the three layers. I only do my job well, and I don't care about other things. The business logic layer should be the focus of designers and the most widely used design mode. The key to the business logic layer design is to achieve loose coupling as much as possible, if there is a call relationship between classes in the business logic layer, this is a bad design. Furthermore, if you publish the interfaces of these loosely coupled functional modules as a service mode (such as Web Service), OK is SOA.

4. Business appearance layer:

Function Description: integrate various subdivision functions in the loose business logic layer, and publish them as a unified sub-system interface. This is also a design pattern.

The business appearance layer should further encapsulate the business logic layer. This is useful only when there are many business logic functions, but they are related to each other. As I said just now, the business logic layer should be loosely coupled as much as possible, but there must be a connection between various businesses. This work should be handed over to the business appearance layer. You need to combine several associated business logic into a subsystem, and then implement this connection in the business appearance layer and release it.

I have seen many projects with a business appearance layer, but the business appearance layer only encapsulates a method in the business logic layer. In addition to increasing the workload, this solution has no benefits. It is better to call the business logic layer directly.

5. Presentation Layer:

Function Description: The data obtained from the user control or obtained from the business logic layer is displayed and cannot be processed.

At this layer, if an SQL statement appears, it should not be. In web projects, some mandatory verification items (in fact, this is part of the business logic) are often performed on the client due to efficiency, but this is worthwhile.

It is good to know what it is. The program structure is clear, which facilitates debugging, expansion, and reading.

Hierarchy in Software System Architecture