Enterprise Application Framework (iv) What should I say in this series?

Preface

This series has already been written into three articles, which have been affirmed by some friends and opposed by some friends. In the first three articles, I have been focusing on coding and seldom involves theories. Therefore, many friends think that what I write is superficial and has no highlights. Maybe my level is really limited, let everyone live up to expectations. This series has not been updated for more than 20 days. One is because the time is tight, and the other is because I am working hard to build a case, however, it is not easy to build a case that can cover all aspects of the enterprise-level application framework as much as possible. However, writing enterprise-level application frameworks without cases is nothing more than a discussion on paper. At present, my case framework has not been completed yet, and some things have not been straightened out, But I know clearly that what I want to interpret is a programming idea, so in theory, I want to explain what I want to say in this series.

Is the layer-3 architecture outdated?

Some of my comments mentioned that the three-tier architecture is outdated. I do not agree with this. The three-tier architecture is a classic software layering concept, and it is not outdated. Many people have suggested that it is not enough to divide three layers. I agree with this. Therefore, when we are working on a project, we can expand several layers above the three-tier architecture idea based on the project's needs to form a multi-tier architecture. However, everything comes at a cost, with more layers, the performance of the program is relatively worse, and programming is more complicated, because each layer must provide the corresponding implementation code, so a good architect, we should have a reasonable control over the specific layers of the project.

As a layered architecture, the three-layer architecture does not provide us with specific implementations. Therefore, the quality of a framework based on the three-tier architecture is closely related to the level of architects who build it. If you see a framework based on the three-tier architecture very disappointed, then obviously, it is the real-world implementation of this framework that has disappointed you, not the layer-3 architecture. As a software layering idea pushed by Microsoft, the three-tier architecture certainly has its own value. My current case framework is also expanded from the three-tier architecture idea, in essence, it still belongs to a three-tier architecture, but it is only divided into one service layer. This is like asking if MVC is Asp.net or if EF is ado.net. If you say no, it will make a joke, because both MVC and EF have made some expansion and encapsulation based on the latter, and then started a new name, Microsoft would like to do something like this.. Net Program, to reflect its height .......

Three-tier architecture

　UI Layer: I don't want to talk about this layer, because you already have some mature technical ideas. If you adopt the WPF and siverlight technologies, the mvvm programming mode will certainly be your best choice; of course, you said that you do not like front-end technologies of these plug-ins. If you like to write HTML, CSS, and JS on your own, it is clear that Microsoft's MVC framework will make you feel like a duck; if you really don't have MVC, it doesn't matter if you only use webfrom. Try to use the MVP idea to write your code. Speaking of this, I would like to remind you not to equate the architecture with the framework. The architecture is a layered idea, but the framework is a specific implementation. You can refer to the commonly used WPF, Silverlight, the MVC framework is actually just an implementation of the UI Layer in a three-tier architecture.

Business logic layer: Many people do not have a deep understanding of this layer. They think that as long as they can receive requests sent from the UI Layer, implement the relevant business functions step by step (of course, the data access layer may be called to achieve persistence) and finally return the results to the UI Layer. Such a layer is the business logic layer. Of course, I admit that I can't say this is wrong. At present, I feel that the business logic layers of most companies are also designed in this way, which is simple and crude. This type of business organization is well-known.Script ModeIt is a process-oriented programming method. Every business in the program corresponds to a method. This method has no problems for small and medium-sized projects, but if the project is too large, it will not work, A method may contain hundreds of thousands of code (of course you can split it into many small methods), but a real problem lies here, that is, such a small method is everywhere in the program, it is very difficult to understand the business. Think about how tragic it is to jump here when you take over a project and understand the business logic code. I am very skeptical about how many of these methods can be reused.

Based on the above reasons, my case is not intended to adopt this transaction script method, and I decided to adopt the object-orientedDomain ModelTo organize my business logic. Simply put, we need to abstract our business into one object (domain model). When we want to implement some business logic, we only need to call the relevant domain model. Of course, the use of domain-driven programming is far from a single sentence. If you want to elaborate on it, you can write another series. This article is just a simple introduction to the way my business logic layer is organized, I will give you a picture below. Although the code in it is not implemented, the overall organizational thinking will look like that.

The Mode folder stores our domain model (Business Object), and the repositories is data warehousing. At the data access layer, I will discuss in detail that services are domain services, this is because it is very likely that some businesses involve multiple domain models and are encapsulated in that domain model, which seems awkward, so they are provided in the form of domain services; event is an event in the domain model, because in principle, the domain model should be a pure business entity and will not be connected to any technology, but sometimes, we must provide some technical methods. For example, when deleting an order, we must send an email notification to the customer. This involves the mail service, however, to ensure the purity of our domain model, we adopt the email service isolated by events. The specific mail operation is injected into the domain model by means of events, now we have a paragraph in the business logic layer .....

Data access layer: Many people have a narrow understanding of the responsibilities of the data access layer. They think that our data access layer only needs to help us implement crud, in fact, the data access layer is far from as simple as we think. Crud is a required function. In addition, it must help the business logic layer to eliminate the differences in specific data access technologies, which requires it to provide a unified data access interface, if you have read the first three articles, I believe you will not be unfamiliar with this aspect. I think an excellent data access layer should also support the work unit mode and warehouse mode, and be able to effectively control various problems caused by concurrency, if you can do this without using the ORM framework, congratulations, you will be a good Microsoft expert. For the first three articles, if I use ADO. net to implement the data access layer. Obviously, this will be a huge project, which basically requires me to re-write a framework similar to Microsoft EF, obviously, I do not have such strength. The following describes the work unit model and storage model.

Work Unit Mode: In fact, it has already been implemented for us in EF. When we add, delete, modify, and query data, we do not submit requests to the database every time, instead, it records the change status in the memory and writes the changes to the database once upon clicking submit. What are the advantages of this operation? Obviously, the first step is to reduce the number of database accesses and improve the performance. Second, all operations are committed at one time, which can well support transaction operations. The work unit mode is easy to describe and can be easily implemented using the EF framework. But let's imagine how to make it happen if you want to implement it yourself?

Warehousing Mode: In fact, this mode is often used, but we didn't notice it. For example, we will create a data entity for each table in the database and a specialized database entity class for operating this entity. Obviously, this database entity class is a warehouse, for example, the orderdal class in the data access layer in my previous articles, is warehousing so simple? As mentioned above, our business logic layer will adopt a domain model to organize business. Since it is a domain model, it must be an abstract business object, and the business object must contain data and behavior. For example, the domain model corresponding to an order will certainly contain all order details of the order. His behavior must include crud for the Order details. At this time, the solution of our warehousing class is the crud targeting our order domain model, which is obviously a multi-table operation. In the warehouse, we must not only implement the crud for the Order table, but also help it implement the crud for the Order details in the model. Maybe you think this is easy, what if we still have customers in the order table? Obviously, it is not as easy as you think to implement data warehousing for Object-Oriented Domain Models. Fortunately, EF also provides corresponding support, if you want to write an ado.net warehouse for the domain model on your own, you can imagine the pain ......

IOC and AOP: Obviously, we must shield the technical differences at the data access layer for our business logic layer. In the business logic layer, we call the interfaces provided by the data access layer. However, no matter what kind of interfaces, we must provide instances. In the first three articles, I read the configuration file, the reflection method is used to provide instances. Obviously, this is not a good method. We can use a more concise method to use IOC containers to help us create instances, such as spring.net. In fact, the purpose is the same as what I mentioned in the previous three articles, is to remove the dependency of the business logic layer on the data access layer. But now I want to perform some data verification operations every time I call the data access layer method and record exceptions to logs when a problem occurs in my data persistence operations. However, I do not want to write data verification and logs in the call methods at the data access layer and business logic layer. Because every method call must be written, no doubt the code is redundant. Of course, you can also write a base class for corresponding operations, but this is not elegant. At this time, we need the AOP technology. The AOP container allows us to perform some logic processing before or after calling the method attributes of the created instance, these logical processes can be easily injected into the configuration file ......

Service Layer: This is the layer I added on the basis of the three-tier architecture. Why is there a level? Our business layer is encapsulated into a domain model and domain service, and our specific business needs to call the relevant domain model and domain service for implementation, therefore, the main problem to be solved at the service layer is to call various Domain Models and domain services to implement our business. To call a domain model, you must be able to create an instance of the domain model, obviously, this work must be implemented by domain warehousing at the data access layer. Therefore, the service layer must add references to the data access layer and business logic layer, it will coordinate the entire domain model and domain service to complete the business. In addition, the service layer must solve a problem, that isDtoAndDomain Model. Our data warehouse operations are all about Domain models, and the UI Layer does not care about our domain models. The data it passes or the data we want to display is often very simple, this requires that our service layer be able to flexibly convert DTO and Domain Models. A third-party framework, automapper, is recommended here.

Distributed service: In my case, I do not intend to allow the UI Layer to directly reference my service layer and directly call our related services. I plan to use the WCF distributed technology to expose our services. In this way, there are two points. First, the UI Layer is completely decoupled from the service layer. Second, when our company wants to transform projects into mobile apps, we don't even need to modify a little bit of code. At the same time, our business functions can be flexibly called by other systems. Of course, this is a knowledge of distributed systems. If I want to elaborate on it, I can write a series. At present, all the business systems of our company adopt distributed deployment. When this series is finished, I may write a series of distributed systems according to the Company project.

Summary: In this article, I will give a rough introduction to what I want to write in this series. Although it is not very advanced, it is very small and dirty, it also covers the enterprise-level application framework I have mastered and the knowledge points that should be learned and paid attention. This series is very simple, but it is really difficult to integrate a case. Over the past 20 days, I have been writing related cases, but I have found many things I cannot handle. No matter how it works, I will stick to writing this series. I hope you will be able to support me, instead of winning the lottery. Something that doesn't help you or has no depth, I don't have the courage to enter my blog. It's very late. I hope everyone in the garden can become a bull.