Draft Design of. Net distributed architecture development practice II

Preface:

This article is called the draft design because the design is completed on paper. Reflects a process of thinking.

The topics in this article are as follows:

1) Proposal of the first data layer sketch

2) thoughts on the data access layer

3) Proposal of the second data layer sketch

1. Proposal of data layer sketch

Richard started his design and immediately started typing on his computer.Code. In addition, we started to use pen and paper.

Because he thinks: WriteProgramIt is not always the case that you have to go to the computer. What you think in your mind is the most important thing. Often, when designing a program, you have already implemented the entire function in your mind, even the code has been written in detail in the mind, and it has been run, debugged in the mind.

This is because Richard wants to propose a better architecture and a more powerful one.EnterpriseLevel Architecture, so it is necessary to refer to some successful cases. Richard also thought of the recommended architecture organization methods and suggestions of Microsoft best practice (it is important that you are not familiar with best practice, will not affect reading ).

Then Richard's first sketch came out:

The proposal of an architecture organization method is not just put forward. The design and proposal of a new architecture must first understand the problems you need to solve, and do not over-design them. (This process is very difficult and often requires trade-offs. Therefore, as the architect, the idea of trade-offs is very important: time, resources, and funds must be considered ). Some other design architectures may be referenced at the beginning, or even imitated, but as the thinking goes deeper, those representations will be gradually removed.

At the same time, when we started designing, we didn't say that we had to design a very powerful thing immediately. The architecture design capability was also being improved in the process of gradual evolution and thinking.

2. Thoughts on the data access layer

Before explaining why the architecture is designed like the figure above, let's first discuss some of the previous project issues:

Concerning the data access layer (DAL:

1. Dal relies heavily on entities generated by LINQ. It can be said that in the previous project, the data access layer can be usedTechnologyIt's already pinned to the LINQ. This is not to say that LINQ is not good, and there is no room to emphasize the Access Technology in Dal, and it is not flexible.

A) in the design process of the architecture, it is necessary to consider future technological changes and replacements. It is possible to useSQLBut the Entity Framework is used in Project B. Because our goal is to develop a flexible general architecture that supports different data access technologies. It is possible that all future projects will only use an access technology. However, the most architecture designers, especially those who want to evolve from the architecture to the framework, need to reserve an interface for replacing the technology.

2. There are not many underlying mechanisms such as exception handling in the Dal.

A) in the project design process, some underlying mechanisms are used in almost every logic: Exception Processing, log tracking, cache mechanism, transaction mechanism, and security verification mechanism. It was not found in the previous Dal. Maybe you don't think that some mechanisms are needed, or you don't understand why.

Because a powerfulSoftwareYou can't just crash because of some exceptions or errors, or pile up a lot of code. Some of the mechanisms mentioned above: exceptions, logs, and their values are often used during software maintenance. Based on the log records, you can find out where the software is faulty.DatabaseDisconnected, or which operation process caused the problem. Some mechanisms reflect value at runtime, such as caching, verification, and transactions.

However, when using these underlying mechanisms, we also need to weigh them. A comprehensive consideration, such as the cache mechanism, is that we need to understand the data to be cached, where the cache is, and how to encrypt the cached data, how long is the cache and how to refresh expired data. A lot of things to consider.

3. The data source only considers the database. In fact, this is not a problem of the previous project, but it is necessary to raise it here.

A) generally, when we develop a project, the data source is often a database. You just need to directly operate the database, but you have to consider the following: if our project does not have its own database and our data source is from another company or service interface, what should we do? As the architect, you need to consider this. Net distributed architecture development practice Draft Design

It may be clear on the day when the project is finalized whether to design your own database or retrieve data from other places. However, a common architecture requires the ability to reserve interfaces for other data sources.

Here, there may be a bit of over-design experience. At first, the architecture used in project A did not consider other data sources, but what should I do if it appears in Project B? Then the architecture must evolve and be improved to adapt to this situation.

As mentioned before, there is no need to design a strong architecture as soon as possible, but to improve and evolve in the project. I didn't take it into consideration at the beginning. I will add it later. (Relatively tangled ).

The above is just a close reflection from the data-layer Dal perspective. The Dal eventually provides data for the business-layer Bll, so we should consider the method in which the dal is called by BLL, in view of some of the previous considerations, we can draw a point: do not let BLL wait for the implementation details of the Dal, so the interface seems to be a good solution, and the provider mode also seems to be useful.

Therefore, Richard decided to add the interface layer before Dal and BLL to decouple.

3. Proposal of the second data layer sketch

This figure is basically the same as the previous one. It only makes a modification and adds some problems mentioned in the previous discussion.

As I think deeply, I gradually find that the source of the data source can be many databases, common text, XML, and so on. Different data sources provide different providers. In fact, retrieving data from other service interfaces is also a source. The figure above separates the service agent separately, mainly because it is special.

In addition, the basic functions in the figure, such as log and exception, are used everywhere.

At this time, Richard also flashed some exceptions in his mind:

1. data source is not exits: the data source does not exist, because this problem is very common. For example, when the project is running, the database is disconnected or remote services cannot be accessed, and so on. Therefore, this exception must be handled.

2. Time Out: timeout. This exception is common because the obtained data is too large or the remote data source connection times out.

3. If the data source is data provided by other service interfaces, you may need to convert the data format when obtaining the data. If the format is incorrect ,. Or the sent data does not comply with certain rules. This exception must be handled because the data may involve security issues: whether the data is correct or tampered.

The program must handle these exceptions: It throws native exceptions, and then the business layer determines if to handle them; or it decides to call exception packaging another exception and then throw it; in the end, simply execute your own processing on the Dal, and then give a friendly prompt to the business layer. If the data source is a remote service, if the service is disconnected, what kind of policy is used during the exception process: simple processing, such as throwing an exception and logging, or do some restoration operations, such as trying to reconnect.

In the first diagram, an interface is defined on the Dal for coupling, but some modifications have been made in the second diagram-providing the Dal as a service. The reason for this change is that when I started thinking, I thought that the Dal of the underlying design was only used for BLL. We can find that data can be obtained from remote services in the Dal, so we may use the Dal here as a service designed for other people, that is, the Dal here is the data source of the remote service. So we made the above changes. However, this thinking will be improved because of the problem (readers can first think about what the problem is ).