Rebuilding the data room Charging System (2)

Next, rebuild the charging system for data centers (I)

Ii. Outline Design

The use case diagram is completed, and the requirement analysis specification is improved in combination with the use case diagram. The number of revisions to the requirement analysis specification is missing. With the use case diagram, it is natural to enter the outline design stage. I think this phase is to solve the basic architecture of the system with the package diagram. The three-tier architecture (in line with the idea of High Cohesion and low coupling) is adopted here, and some design modes are combined.

 

View my package diagram below:

As you can see, this package diagram is evolved from the most classic three-tier UI-BLL-DAL joining the design pattern.

The abstract factory model is used to facilitate database replacement.

The application appearance mode is used to solve the problem that the coupling between the UI Layer and the BLL layer is too high. The UI Layer does not have to know the existence of The bll layer) it knows which classes at the BLL layer are responsible for processing which requests, and it proxies the UI requests to the appropriate BLL layer classes. Make external calls more convenient.

 

3. abstract classes at different layers

When we determine the architecture of the entire system, what we need to do next is to refine the process from macro to micro.

1Abstract object class

In my opinion, the first step is to abstract the entity layer class (entity), because the information system operates and processes data and must first have data. At this time, we need to return to the requirement, understand the user's data requirements, and design the Database Based on this. For database design, see my article:

Database Design third paradigm

Another article reposted on Database Design Experience

 

After the database is designed, We need to abstract the entity classes according to the tables in the database. In the data center charging system, the entity classes basically correspond to the tables one by one, and one table maps to one entity class, the table field is the attribute of the object class.

 

The entity layer does not belong to any layer in the three layers. It is an independent layer that can be used as a combination of custom variables.

 

Let's take a look at the Entity class I abstracted:

See the figure below:

, We can see that there is an en_publicfield class. This class is not mapped by data tables. It is a class that loads public variables. In the system, try not to create variables outside the class. we can create an object class and use this global variable as its attribute. Therefore, the number of entity classes may be the number of redundant tables.

 

2, Data access layer

After the entity layer is completed, let's take a look at the data access layer (DAL). The main task of this layer is to directly operate the database and complete addition, deletion, modification, and query of data. Here we still abstract the classes at the Dal layer based on the data tables, basically a table corresponds to a class, so when we add a new table, we can directly add a new Dal layer class, it is in line with the "open and closed principle ".

In addition, because the classes at the Dal layer perform operations on the database directly, there are mainly four methods for writing in this class: add, delete, modify, and query. But there will be different parameters and different return values according to the actual situation.

 

An interface is added here to use reflection and abstract factory to prevent database replacement. See the following section.

 

Interface:

Note: we can see that there is an interface called itime, which is used to obtain the server time, so the number of Dal layer classes may also be the number of redundant tables.

Dal implements idal Interface

 

Abstract Factory mode + reflection + configuration file

3, Encapsulate the business logic, constituteBllLayer class

After the data access layer is completed, we have laid a solid foundation. Next we will look at the use case diagram. Basically, a Use Case encapsulates a function. The bll layer class can be divided based on functions to integrate operations related to this function into a BLL layer class. here we need to grasp the granularity and balance it.

Try to comply with the single responsibility principle. A Class completes a function, that is, do not call each other between classes on the BLL layer. Although it can reduce the amount of code, it will increase the complexity of the system, this causes strong coupling between modules.

For example, we need to query the recharge record table during "checkout". We also need to query the recharge record table when "querying recharge records, we should set the query method in the checkout class of The bll layer, and also set the query method in the query recharge record class.

 

In special cases, cross-call is required. For example, if an operation needs to be repeated continuously (more than three times), we usually extract it for external calls. At this time, we should move the call up, that is, we should not call the BLL layer class method in The bll class, but on the BLL layer, we use the appearance mode here, therefore, the method of the two classes is called at the top layer of Bll, namely the facade layer (see the package diagram above.

 

For example, you need to check whether the card number exists in "computer" and "offline", and check whether the card number exists. You need to check "recharge", "Return", and "Registration Card. At this time, we can extract the check card number operation. When we call it, instead of directly calling it in The bll layer, we promote it to the facade layer for calling. That is, before calling the machine, we call "check whether the card exists" first ".

 

See my BLL layer.

The rule mode is used at the BLL layer:

4, ReduceUIAndBllCoupling, use the appearance mode, add the appearance (Facade) Class

Bll layer has many very small classes, which makes it difficult to call the UI Layer. The appearance class layer provides a simple interface for the UI Layer, this greatly reduces the coupling between the UI Layer and the BLL layer. It can also be seen as a coarse granularity.

See the figure below:

5, Interface layer (UI)

The class at the interface layer is our form class. There are many forms and the class at the UI Layer.

See the figure below:

Iii. Design Model

The above mentioned design patterns include Abstract Factory patterns, appearance patterns, and policy patterns. Use the template method mode in The bll layer. In the UI Layer, the observer mode is used to dynamically change the status bar. If you use an external report control, you may use the adapter mode.

 

Conclusion: The above design is only a personal point of view and needs to be verified during the coding process.