I, the first time I used the appearance mode, it 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 frame

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, you guessed it, this Baby is going to draw drawings. Ugly)

Let me briefly introduce it first.

1. Regarding transactions, declarative transactions are adopted, which are added to the service layer, and the granularity is the entire class ! First of all, I feel that the entire class is annotated and unified into the same default configuration. This approach is 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 idea is that because our unified external interface is the facade layer, I think it is a way to control transactions to the facade layer. It is no longer necessary to add class transaction annotations at the service layer, and even add transaction management to the base class baseservice. But what I told me at the time was that since 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 haven’t studied Dubbo’s mechanism and protocol carefully. Not sure is there any conflict or connection with adding transactions to the facade)

2. The role of appearance mode.

quoted from “Dahua Design Pattern”: Facade: a group of subsystems The interface provides a consistent interface. This mode defines a high-level interface that makes this subsystem easier to use.

The use scene of appearance mode, three stages: First, in the initial stage of design, it should be conscious Separate the two different layers; secondly, in the development phase, the subsystems often become more and more complicated due to continuous reconstruction of the fireworks. The addition of the facade can provide a simple interface and reduce the dependence between them; third When maintaining a large legacy system, it may be very difficult to maintain and extend the system. 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, so that the new system can be connected to the facade. Object interaction, facade and legacy code interaction all complex work.

And our system, in a strict sense, can be regarded as a need 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 the service, so adding this layer does not make much sense. Because of the addition of the facade layer, it did not simplify and decouple the dependency of the controller in the current project to call the Dubbo service interface, because the interface is basically the same as the service layer! (My current humble opinion)

Moreover, the appearance mode is a structural design mode. What is a structural type? ? ? ?

II. API Gateway

When it comes to the appearance model, I think of it being done recently and planning to introduce the project’s API gateway service. Inside, I felt the exquisite and wonderful appearance. Hey (come a beautiful picture):

< span style="font-family:KaiTi_GB2312; font-size:18px">API gateway, in fact, is equivalent to the appearance, the client uniformly calls the service 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, decoupling the service and the client.

2, decoupling the client and service deployment environment.

3, provides the best API for each client.

4, reducing the 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 a combined façade interface.

For the API Gateway paragraph, please refer to:

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

Three. Summary

The summary of this time is actually two sentences:

1, such as No need, don’t add entity

2, if the entity has been added, it must be used to its maximum function (and it is Good use)

The third point is a reflection on myself: I need to study in depth Some things must be persuasive 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!