. NET normal three-tier to Factory mode--thread unique + cell operating mode->webservice distributed three layer

The idea of layering in the software world is everywhere

Mainly to improve the maintenance of software systems, extensibility, reusability and decoupling, etc.

The three-layer architecture of software is the embodiment of the most basic layered thought

The structure diagram is broadly as follows:

As a result, developers can focus on only one layer, without worrying about how the next layer is implemented

But the most basic three-tier architecture is clearly not enough in a software system.

Because it brings advantages, but also with many shortcomings, such as high coupling, often appear to modify a layer of code the other layer will also be a substantial reorganization

And when the demand changes, such as: the original development of the use of the MSSQL database, and now the need to replace the MySQL database

Changing the DAL layer will cause the BLL layer to be redesigned as well.

You can then use the three layer of Factory mode

The basic framework is as follows:

In fact, the code for the BLL and the DAL layer implements their interface layer interface respectively.

This embodies the principle of software design for interface programming

Why do I need more interface layer implementations?

As long as the interface of the Idal layer is implemented

Whether it is the dal of MSSQL or the DAL layer of MySQL can be arbitrarily replaced

A factory class to provide entity objects for the Idal interface layer

In the BLL layer, you just need to call the methods in the Idal interface layer without worrying about who did it and how it was implemented.

At this time, if you want to change the database to change the code to significantly reduce

Only need to modify the relevant code in the factory class can be, the BLL layer basically no change

But it's still going to change the code.

Violates the principles of software design in the development of extensions, the principle of closure of changes (open-closed principle)

We can use reflection technology to solve this problem.

We can reconfigure the assembly name and namespace where the data manipulation classes reside in the interface and DAL layers in the idal layer.

Dynamically create the Entity object of the DAL layer and turn it into an interface in the Idal based on the information in the configuration file in the factory class using reflection

It is then provided to the BLL layer for use

Now if you want to replace the database only need to change the corresponding assembly and namespace information in the configuration file is done, the code does not need to modify a row

(Even better, you can put the configuration information in the database, and then provide a configuration page to switch configuration information operations, so that even the configuration file does not need to be modified!) ）

In

Because the crud methods for each entity class are similar, abstracting a Ibasedal interface prescribes a crud approach and allows all interfaces of the Idal layer to inherit from the base interface

Similarly, for the data manipulation class of the DAL layer, a Basedal base class is abstracted, which implements the Crud basic method stipulated in the Ibasedal, and implements the code reuse again.

But in a lot of scenarios (such as Web sites)

Because of the large number of users, can cause a lot of problems, such as data out of sync and other multi-threading problems

This problem can be improved by using a unique scenario within the thread

The only thing inside a thread is to guarantee a user request, and the access process is only manipulated through a single data context, so there is no data clutter due to caching and so on

Several key points were added based on the three-tier architecture of the factory model:

1. A dbcontextfactory factory class is set up on the data access driver, where the unique data access driven context is obtained from the data slot through the CallContext method within this factory class

2. The Dalcontext layer is added on top of the Idal interface layer, which is designed to give the BLL layer a unified portal to invoke the Idal interface, but its more important function is to implement the unit work through a public SaveChanges method

3. As with the data Access driver layer, a Dalcontextfactory factory class is set up at the Idal Unified entrance to ensure that the portal is unique within the thread

So what is unit work

For example, in a business need

To add to the Users table

To delete a roles table

Then modify the intermediate tables for users and roles

Then this program will interact with the database three times

But if you put three action lines into a cache, wait until the last commit to the database

This reduces the number of interactions in the database and increases the throughput of the database

This is the unit work mode.

This functionality can be easily implemented in EF (the last step in the data manipulation class is not to use the SaveChange save operation of the data context, but to encapsulate it into dalcontext. Enables the BLL layer to call Dalcontext's SaveChanges method for uniform save changes after performing a series of business operations)

The general idea of using ADO is to put the SQL statement you want to execute into a cache queue

By another worker process through polling (every once in a while, this interval is very small) from the cache queue out of the SQL statement submitted to the database

And finally the distributed three-tier architecture.

We can use the webservice to achieve a simpler implementation of this framework in each layer of the WebService through the basic services of the layer (simple three layer, the factory three layer or the unique + unit in the thread three layers, etc.) to get the corresponding interface and through the methods of these interfaces to receive and process the previous layer of the request sent

. NET normal three-tier to Factory mode--thread unique + cell operating mode->webservice distributed three layer