The introduction

I am interested in architecture. I would browse blogs and read books when I have something to do. Then the team leader asked me to share my knowledge about architecture. Let’s start by writing a blog to get your thoughts straight. MVC pattern, in my opinion, is the most powerful architectural pattern! Can give a lot of architectural inspiration (including MVP,MVVM later). For small and medium-sized apps, simple MVC or MVPC mode is more suitable. This article is based on the IDEA of MVC to write.

Model and thin?

As early as a few years ago, there was a long dispute about the concept of fat and thin model abroad, and the final result was nothing… Both the fat model and the thin model have their own advantages and disadvantages. So what is a fat and thin model? The so-called fat model is that your Model layer contains some weak business, thin model is a pure model, only attribute mapping. For example 🌰 : let’s say your UserModel is familiar with gender, but the fields returned in the background or stored in the database are 0 and 1, and you need to determine male and female based on this field. If you are a fat Model player, very simple ah, I do these simple business judgment in my Model layer, when the ViewController needs to directly use it. However, the fat Model is difficult to port, and modification may cause some unnecessary trouble. Thin model player is different, my model can be very convenient direct ORM mapping, I need to use in my ViewController to judge. The result, however, is a violation of the DRY principle (Don’t repeat yourself). Because much of the redundant code is not abstracted, the VC layer looks bloated.

As for my attitude, I prefer fat Model. The traditional MVC model will make the VC layer very bloated, many people have proposed to slim the VC layer before. As a result, part of the weak business was written in the model, so the fat model was born. As for the MVVM that followed, the MVVM was more abstract.

What is architecture

What is architecture? Maybe a lot of people come up with MVVM, MVC, and list the pros and cons and blah, blah, blah… Personally, I think architecture is that the architect designs the framework according to the current business complexity and business engineers. The purpose is to make business engineers unified, convenient and clear when writing business. And it can be relatively easy to get started, migration, including the subsequent evolution also need to be considered. For small and medium-sized apps, there are not many business engineers and the business is not very complicated. So you can do some simple split (abstraction) based on MVC.

The overall architecture

The totality is MVC based with an added layer of Reformer. The function is to extract some business from the fat Model and some business from the ViewController and put it in the Reformer. So our network layer interface can be designed like this

+ (void)requestBubleList:(BaseReFormer *)reformer
                     xxx:(NSString *)xxx
                callBack:(void (^)(int code))callback;
Copy the code

Business programmers just need to focus on what they need to do data processing, business logic, written in the Reformer. Then pass in the Reformer and the parameters required for the request, and you don’t really need to know what the network layer does. The Reformer handles business and data, the Model for data management, the View for data presentation, and the ViewController for coordinating the Model and View and responding to interactions (which may involve parts of the business).

In general, the function of C layer in MVC is weakened. In the design process, less inheritance is used, more combination is used, and the reusable code is managed by management class. I call this the MRVC framework.

Overall code framework

The framework is designed and differentiated based on business, in order to better division of labor and cooperation, and better code migration. The first Util contains common code, business-neutral utility classes. Such as various third party encapsulation, classification. The second ‘Dao’ contains utility classes that are relevant to the overall business, such as common databases and common network interface apis. The third is the business involved in App. Lib is a third-party library without a POD library import. Res are Assets, pictures, Assets. Out there is the Base class, and in the Base class don’t put the business-related code, just put the basic configuration and basic API.

Business code layer framework

When it comes to the framework design of a specific business, we will divide the network layer into different businesses and scatter them into various business modules. You can see that at the top is the source of the data (either the background return or the database). The Mediator layer in the middle is used for the traffic jump, and most of the time we write a page jump like this:

XXXViewController *controller = [XXXViewController new];
[self.navigationController pushViewController:controller animated:YES];
Copy the code

The disadvantage of this is that the program monkey A needs to jump to A business page that has been completed by the program monkey B, but A is not familiar with THE code of B, so he has to ask B. If B is not there, he has to find it, which may take A long time, and it will be even more embarrassing if he needs to take parameters. Therefore, we can add a Mediator layer of B business for the jump. The jump interface is well designed, for example 🌰 :

Usermediator. h /** Jumps to @param from the jump page @param user_id User ID @param nickName */ + (void)pushUserInfoContoller:(UIViewController *)from userID:(long)user_id nickName:(NSString *)nickName;Copy the code

When we need to use, just call [UserMediator pushUserInfoContoller: self userID: 10086 nickName: @ “China mobile”]. For A, look at the Mediator layer documentation to use it.

Therefore, the framework design of the business layer can be shown as follows:

conclusion

Benefits of this architecture 1. The overall design is divided into business modules, and there is no direct coupling between business and business, because there is more Mediator layer in the middle. So the reuse and migration of business is relatively simple, and it can be further iterated if you want to modularize in the future. If decoupling is also required, the Runtime and dictionary pass-throughs are used, but this is relatively expensive and not intuitive enough for the API. 2. The overall design is MRVC, so it is the lightweight V layer and the Model layer of the mapping level, and the intermediate business is basically in the Reformer layer. If responsive programming is required, design changes can be made in the Reformer layer. 3. Use less inheritance and more composition. For the convenience of code migration, the phenomenon of pulling out radish and bringing out mud is very rare. 4. The modules of the network layer interface can be consistent with the background architecture, which is good for the overall architecture.