I use it for the first time The appearance model should be more than 3 years ago. At that time, a toll system was built, and a layer of facade was added between the U and B layers at that time. At that time, when dealing with some complex business logic, I felt the benefits of adding the appearance layer, but for some simple (I mean, many methods in the facade at that time simply returned the results of the method execution of the B layer) business , I always feel that it is unnecessary. So, how powerful is the appearance model? ? ? ?

First, the current framework

Later, in the development of the project, many design patterns were used. But the proportion of appearance is really not that big. So recently, the company’s framework has added a facade layer on top of service, registering the interface service of the facade to the Dubbo center, and providing API services uniformly to the outside world. The entire designer has no problem, but for the statement of the architecture group and the current usage, let me talk about my thinking (I think I am right, but I am not sure, just briefly talk about my opinion)

First of all, let me talk about the call relationship in the framework of the project as a whole (haha, guess no Wrong, this baby is going to draw drawings by hand. Ugly)

Let me introduce it first.

1. Regarding transactions, declarative transactions are adopted, which is added to the service layer, and the granularity is the entire class! First of all, I feel that the entire class is commented and unified into the same default configuration. This approach is It needs to be studied. Because I don’t think that the transaction behaviors required by each method are consistent. To be more extreme, I think that some single-table single data operations do not require transactions! However, my own thinking is because we are unified externally The interface is the facade layer, so I think it is a way to control transactions to the facade layer. It is no longer necessary to add class transaction annotations to the service layer, and even add transaction management to the base class baseservice. But, at the time What I said is that because our facade interface is implemented externally through Dubbo, if you annotate the transaction to the facade, some other problems may occur with Dubbo! (At this point, I have not studied Dubbo carefully. Mechanism and agreement, not sure is there any conflict or connection with adding transactions to the facade)

2, for the appearance mode Role.

Quoted from “Dahua Design Patterns”: Facade: Provides a consistent interface for a group of interfaces in the subsystem. This pattern defines a high-level interface. This interface makes this subsystem easier to use.

the use scene of appearance mode, three stages: First, in the initial stage of design, you should It is necessary to consciously separate the two different layers; secondly, in the development stage, the subsystem often becomes more and more complicated due to continuous reconstruction of the firework. Increasing the facade can provide a simple interface and reduce the dependence between them. ; Third, when maintaining a large legacy system, the system may have been very difficult to maintain and expand. Develop an appearance class for the new system to provide a relatively clear and simple interface for the legacy code with rough or highly complex design. The system interacts with the facade object, and the facade interacts with the legacy code for all the complex work.

This system of ours, strictly speaking, can be regarded as one that needs to deal with the old system, and the business is relatively mature. When changing to a new framework, business logic is reused, but there is not much or no reuse in code. Therefore, to a certain extent, it can be regarded as a new system. Simple analogy to the use scene of appearance, then it should meet the second point.

Let’s look at the purpose of the appearance first:

So, I think the current facade layer is just a simple way to return service, so add this One layer is of little significance. Because the facade layer is added, it does not simplify and decouple the dependency of the controller calling the Dubbo service interface in the current project, because the interface is basically equivalent to the service layer! (Personal current humble opinion)

Furthermore, the appearance mode is a structural design mode. What is a structural design??? ?

Second, API Gateway

When it comes to the appearance mode, I think of the API gateway service that is currently being done and is planning to introduce the project. In this, I can feel the appearance Exquisite and wonderful. Hey (come a beautiful picture):

API gateway, in fact, is equivalent to the appearance, the client uniformly calls services from the API gateway service, and the API Gateway is responsible for integrating specific services.

Look at the advantages of API Gateway (I think a lot of them are like the advantages of appearance mode)

1, decouple the service and the client.

2, decoupling the client and service deployment environment.

3, provides the best API for each client.

4, reduced number of requests/roundtrips. For example, the API gateway can retrieve data for multiple services at once. Fewer requests also means less overhead, which improves the user experience. An API gateway is essential for mobile applications.

5, which simplifies the call of the client, because the API gateway can combine services and provide combinations After the façade interface.

For the API Gateway paragraph, you can refer to:< /span>

Google Translation: Microservice API Gateway Original address: Pattern: API Gateway / Backend for Front -End

Three. Summary

This summary is actually two sentences:

1, if unnecessary, don’t add entities

2. If the entity has been added, it must be used to its maximum function (and it is a good use)

The third point is a reflection on myself: I need to learn some things in depth, so that I can have strong persuasive power from theory and practice. Moreover, in the process of studying this period, I found that my ability to connect with theories and to argue with theories has increased a lot, but the speed of practice is too slow. For example, it took several hours to test the piece of content where the transaction was added to, and then the impact of adding it to different places and performing different operations was tested.

I can do better, come on! Hey, the whole API getaway, a particularly fun thing!