. Net layered architecture (completely separated from each layer)

When it comes to hierarchy, I think of what the Turing Award winner said: any problem in the computer science field can be solved indirectly by adding an intermediate layer; when I first saw this sentence, I could not deeply understand what the real soul of this sentence is. The reason why I want to write this article as a technology enthusiast is more willing to share with you the joy that technology brings to us. I will analyze the real mysteries of the. NET layered architecture from another perspective. Layering: Some programmers with weak technical skills will think of a layer-3 architecture (BLL, Dal, and so on) when they hear it. Actually, layering is a big technical framework, the three-tier architecture only breaks down information flow through three layers for common information systems, during system development, a model layer, a BLL layer, and a dal layer are created in the solution; in fact, if a project is created in this way, it is the same as putting a program in a solution, but you can use folders to separate files. Different technical products have different understandings of Layer 3, sometimes an interface layer is added to allow each layer to rely on interfaces for implementation. For the above BLL and Dal architectures, it is just a human decomposition. The solution looks clear, there is no separation function for the framework, or high coupling and low class clustering;

In a layered architecture, the system is layered in general, which involves the concept of vertical and horizontal directions. A large system can not simply process information in terms of business logic, it may also involve some other logic processing. Here, we cannot just abstract the logic into three layers. The three layers are one layer in the horizontal hierarchy, if you don't see three layers of layer-based focal lengths, you may not find the target in the processing sub-layer of the information stream if you zoom in to the focal lengths. It's abstract;

Break down a large system into three business logic blocks, which is actually the three major layers I mentioned. We will narrow the focal length closer to the Child layers in business logic 1;

 

The big layer of logic 1 is divided into two sub-layers Bll, and Dal, which are our common business logic layer and data access layer; the business logic layer 1 is mainly used to add, delete, modify, and query databases. abstracting it into BLL and Dal is also the three layers we are familiar; in the other two business logic layers, you can break them down into multiple sub-layers. After the sub-layers are separated, you need to solve the specific implementation problems. Then, you can use the C # object-oriented language, the architecture and thinking are both methodological things, and the specific implementation is indispensable; the layer is to determine whether layer-by-layer Isolation is achieved in the development process, without mutual dependency, therefore, the interface layer is used to separate the specific implementation layer. We will change the BLL layer to the BLL interface layer blli and the Dal layer to the Dal interface layer Dali, this allows BLL and Dal to implement the blli and Dali interfaces and completely separate development. This is also the interface-Oriented Programming advocated by Object-Oriented rather than implementation programming;

In the future, BLL layer problems can be completely replaced by another BLL layer, and the Dal layer is also the same; but this is an ideological thing that is not as easy as implementing the Code:

For example, blli B = new BLL (); // in general, the interface is used in this way, but it does not seem as clean as the theory suggests, we are implementing separation by adding a factory;

 

In this case, blli B = new blli Factory (blli interface type) is used. When the factory is called, the interface type is passed as a parameter, in the factory, you can use the interface type to find specific implementation objects. For example:

Public static t getinterfacerealization <t> (type interfacetype)
{

Assembly ass = assembly. loadfrom ("assembly name ");

Type [] asstype = ass. gettypes ();
If (asstype. Length <= 0)
Throw new exception ("interface manager exception: This assembly does not have any implementation classes ");
For (INT I = 0; I <asstype. length; I ++)
{
// Obtain whether the entire inheritance chain of the implementation class has an interface type passed in;
Type oddinterfacetype = asstype [I]. getinterface (interfacetype. Name );
If (oddinterfacetype! = NULL)
{
T = (t) system. activator. createinstance (asstype [I]);
Return t; // return the interface implementation class of dynamic instantiation;
}
}
Throw new exception ("interface manager exception: There is no implementation class for this interface. You must first implement the interface class before searching ");
}

 

Because different projects in the same solution are directly referenced by each other, it is conducive to project development and debugging, however, our BLL and the caller are completely independent and there is no type of call during Program Calling. Therefore, when the solution is generated, the referenced project assembly will not be copied to the execution directory. medium, if you want to omit manual operations, you can call the object at the Implementation Layer before performing the search, in this way, when compilation is generated, the code will check that your called Project assembly will be copied to the execution directory, and will not fail during dynamic search through the interface factory;

In this way, we can thoroughly implement the rules of separation layer by layer. The so-called thinking is the essence of the forward, and I also share with you a little bit of experience through constant thinking, if anything is wrong, please point out. Thank you;