iOS application architecture discusses the organization and calling scheme of view layer

[[135040]]

Preface

After the publication of "iOS Application Architecture Talk", many people urged me to publish the second one quickly. This article was quite difficult to publish because there were so many things going on in the company and I had some personal matters, so I didn't have enough time to write a blog.

Now it’s okay, the second article is out.

When we start designing the architecture of the View layer, the App has often not yet started development, or the App has already released several versions, and then a very thorough reconstruction is needed.

Generally, we will develop the View layer architecture at these two times. Due to the special nature of this timing, we must clearly realize that once the View layer architecture is implemented or finalized, there is very little room for modification after the App is released. Because it is most closely related to the business, even if it is slightly changed, the butterfly effect it causes may not be something that the business side can hold. In this case, when implementing this architecture, we must modify the code diligently and not be lazy. We must also have a full self-skeptical attitude and be careful when making decisions.

The architecture of the View layer is very important. In my opinion, this part of the architecture is the most important part of the four aspects covered in this series of articles. Why do I say that?

The View layer architecture is one of the factors that affect the business side’s iteration cycle

Product managers will generate requirements very quickly, especially when the company is still in its early stages of entrepreneurship. In larger companies, product managers also like to dig big holes to show their presence in front of leaders, such as Alibaba. This results in a very heavy workload for business engineers. Under normal circumstances, it is unlikely that product managers will cut requirements. Therefore, as an architect, if there are some things that can be done or not in the architecture, it is best to do them if you can, and don't be lazy. This can help reduce the burden on the business side, and you can pay more attention to the business when writing code.

When I communicate with some friends, they all complain more or less that their team's iteration speed is not fast enough, or that the iteration speed is unreasonably slow. I think the iteration speed cannot be increased as you wish. There are many factors that affect the iteration speed. The amount of tasks and the complexity of tasks in the first phase of the PRD will affect the extent to which the iteration cycle can be achieved. Putting aside these external factors, from the internal reasons that may cause the iteration cycle to fail to reach a reasonable speed, one of the reasons is likely that the View layer architecture is not well done, so that business engineers need to deal with too many extra things when completing a not-so-complex requirement. Of course, too many meetings and poor engineers are also internal reasons for the slow iteration speed, but this is not within the scope of this article. Also, overtime is not the right way to optimize the iteration cycle, um.

Generally speaking, there are five main reasons for a poor View layer architecture:

The code is messy and irregular

Complex dependencies caused by too much inheritance

The degree of modularity is not high enough and the component granularity is not fine enough

Horizontal Dependence

Architecture design lost its heritage

These five factors will affect the efficiency of business engineers in meeting requirements, thus slowing down the iteration cycle. Other defects in the View architecture will also have more or less impact, but in my opinion, these five are the more important factors. If you think there are other factors that are more important than these four, please put them forward in the comments section and I will add them.

I would like to emphasize the fifth point: the design of the architecture must be inherited. The architecture with inheritance will be very coordinated from the overall perspective. But the actual situation may be that one person leaves and another takes over. Even if the task handover is complete, it is inevitable that different people have different architectural ideas, which will affect the fluency of the entire architecture. To solve this problem, on the one hand, we should try to avoid single point problems and let the architect bring another person when doing the architecture. On the other hand, the architecture should be designed as simple as possible to smooth the learning curve of the successor. When I left Anjuke, I made a guarantee: all the code that came out of my hands will be guaranteed for life. So don't think that you will not care about anything after leaving. This is not only a question of professionalism, but also a question of whether you are confident enough in your code. Inheritance is very important for the View layer architecture because it is closest to the business and has the least room for change.

So when CTOs, technical directors, and team leaders feel that the iteration cycle is not fast enough, you don’t have to rush to recruit new people. The Mythical Man-Month has long said that adding new people cannot completely solve the problem. At this time, if you can look back and see if the View layer architecture is unreasonable, fixing this is also one of the ways to optimize the iteration cycle.

Well, as for the impact of the other three architectural solutions in this series on the iteration cycle, I think none of them has as high an impact as the View layer architectural solution on the iteration cycle, so this is one of the reasons why I think the View layer architecture is the most important.

The View layer architecture is the underlying architecture that is closest to the business

Although the View layer architecture is also considered the bottom layer, it is not that bottom layer. It has the widest connection with the business and has the deepest impact on the business layer code. When all the bottom layers are affected, the View architecture will cause the largest impact on the business layer.

Therefore, once the View architecture is finalized, there is the least room for modification among all architectures. When we first consider the View-related architecture, we not only need to implement the functions, but also consider more things about the specifications. The purpose of formulating specifications is on the one hand to prevent the code of business engineers from corroding the View architecture, and on the other hand to ensure that there is a legacy. Following the specifications, it is always less likely to go wrong.

In addition, the architect will have many things to consider at the beginning, and it is impossible to implement them all in the first version. For an App that has not yet been released, the first version of the architecture is often the minimum complete set of functions. In the development process of the second and third versions, the iteration task of the architecture is likely not just your job, and I believe that you may not be able to handle all of it alone. So you have to make an agreement with your collaborators. In addition, after the first version is released, business engineers will also have many modification opinions during use. Which opinions are reasonable and which are unreasonable must also be screened through the pre-agreed specifications to finally decide how to adopt them.

The standards are not static. When to reject opinions and when to change the standards depends on your skills and experience.

The above is the preface.

What is this article about?

View code structure requirements

About view layout

When to use storyboard, when to use nib, and when to write views in code

Is it necessary for the business side to uniformly derive ViewController?

A small tool to facilitate View layout

MVC, MVVM, MVCS, VIPER

Our School's Heart Method

View processing across businesses

Leave various supplements in the comment section

Summarize

View code structure requirements

Architects don’t just write SDKs and hand them over to business parties. Every company must have a set of code standards, and architects’ responsibilities also include defining code standards. In theory, defining code standards should be common knowledge, but I’m talking about it here because I need to add a standard for View.

Strictly speaking, formulating code standards is not part of the View layer architecture, but it will have a greater impact on the future of the View layer architecture and is also something that architects need to consider when designing the View layer architecture. The importance of formulating View layer standards lies in:

Improve the readability and maintainability of the business side View layer

Prevent business code from corroding the architecture

#p#

Ensure inheritance

Keep the direction of architecture development from being easily influenced by unreasonable opinions

In this section, I am not going to define a set of standards from scratch. Apple has a set of Coding Guidelines. When we set the code structure or standards, we must first comply with these standards.

Then, I believe that everyone has their own set of standards in their respective companies. The specific standards actually depend on the experience of each architect. I just suggest that you add the following point on the basis of your own standards.

The code of viewController should be similar to this:

The main points are as follows:

All properties use getters and setters

Don't initialize your view in viewDidLoad and then add it, as this will make the code ugly. Do only addSubview in viewDidload, then do layout in viewWillAppear (errata 1), and finally listen to Notification in viewDidAppear. As for the initialization of properties, leave it to getters.

For example:

 #pragma mark - life cycle
 - ( void )viewDidLoad
 {
 [ super viewDidLoad];
 self.view.backgroundColor = [UIColor whiteColor];
 [self.view addSubview:self.firstTableView];
 [self.view addSubview:self.secondTableView];
 [self.view addSubview:self.firstFilterLabel];
 [self.view addSubview:self.secondFilterLabel];
 [self.view addSubview:self.cleanButton];
 [self.view addSubview:self.originImageView];
 [self.view addSubview:self.processedImageView];
 [self.view addSubview:self.activityIndicator];
 [self.view addSubview:self.takeImageButton];
 }
 - ( void )viewWillAppear:(BOOL)animated
 {
 [ super viewWillAppear:animated];
 CGFloat width = (self.view.width - 30 ) / 2 .0f;
 self.originImageView.size = CGSizeMake(width, width);
 [self.originImageView topInContainer: 70 shouldResize:NO];
 [self.originImageView leftInContainer: 10 shouldResize:NO];
 self.processedImageView.size = CGSizeMake(width, width);
 [self.processedImageView right: 10 FromView:self.originImageView];
 [self.processedImageView topEqualToView:self.originImageView];
 CGFloat labelWidth = self.view.width - 100 ;
 self.firstFilterLabel.size = CGSizeMake(labelWidth, 20 );
 [self.firstFilterLabel leftInContainer: 10 shouldResize:NO];
 [self.firstFilterLabel top: 10 FromView:self.originImageView];
 ... ...
 } 
 
 This way, even if there are a lot of properties, the code can still be kept neat, and the initialization of the view is left to the getter. In short, try to avoid the following situations:

 - ( void )viewDidLoad
 {
 [ super viewDidLoad];
 self.textLabel = [[UILabel alloc] init];
 self.textLabel.textColor = [UIColor blackColor];
 self.textLabel ... ...
 self.textLabel ... ...
 self.textLabel ... ...
 [self.view addSubview:self.textLabel];
 }

This approach is not clean enough, just throw it all into the getter. Regarding this approach, there is an article in Tang Qiao's technical blog that is different from the approach I advocate, which I will discuss in detail later.

Put all getters and setters last

Because a ViewController may have many views, just like the code sample above, if getters and setters are written in the front, the main logic will be dragged to the back, and others will have to scroll through a long list of getters and setters when reading, which is not good. Then ask business engineers to allocate the positions of code blocks in order when writing code, first life cycle, then Delegate method implementation, then event response, and then getters and setters. This way, later readers can save a lot of effort when reading the code.

Each delegate should have the corresponding protocol name. Do not write delegate methods everywhere, but write them in one area.

For example, the method set of UITableViewDelegate is written with #pragma mark - UITableViewDelegate. This has the advantage that when others read a Delegate implementation method that they are not familiar with, they only need to hold down the command and click the protocol name, and Xcode will immediately jump to the part of the code corresponding to the protocol definition of this Delegate, saving them from searching everywhere.

Open a code area specifically for event response

All button and gestureRecognizer response events should be placed in this area, not everywhere.

Regarding private methods, under normal circumstances, ViewController should not be written

It is not a delegate method, event response method, or life cycle method, but a private method. Yes, normally there are no private methods in ViewController. These private methods are usually used for small functions such as date conversion and image cropping. Such small functions can be written as a category or a module, even if the module has only one function.

ViewController is basically the carrier of most business, and its code is already quite complex, so if you can avoid putting things that are not closely related to the business in ViewController, don't put them. Another point is that the function of this private method is only used by you at this time, but it may be used in other places in the future. Separating it from the beginning will facilitate future code reuse.

Why do you ask for this?

I have seen countless ViewControllers with messy code layouts, a delegate here and a getter there, and the ViewController code is usually very long, which gives people a headache just by reading it.

By defining this specification, the ViewController can be clearly organized, and the business programmer can easily distinguish which ones are more suitable and which ones are not suitable in the ViewController. In addition, it can also improve the maintainability and readability of the code.

About View layout

This is the question that business engineers cannot escape when writing Views. Whether using Frame or Autolayout, if it is not carefully designed, the layout will be terrible.

Using CGRectMake directly is not very readable, and you cannot know the positional relationship between views just by looking at the numbers. Using Autolayout is a little more readable, but the length of the generated Constraint is too long, and the code does not look good.

For Autolayout, you can consider using Masonry, which will make the code more readable. If you are still using Frame, you can consider using this project.

This project provides convenient methods related to Frame (UIView+LayoutMethods), which basically cover all layout requirements and are very readable. After using it, you can basically say goodbye to CGRectMake. Because Tmall has only recently switched to support iOS6, Tmall used Frame layout before. In the Tmall App, the layout of the home page and some pages of Faner uses these methods. Using these convenient methods can achieve twice the result with half the effort.

This project also provides a convenient method for producing Constraints under the Autolayout solution (UIView+AEBHandyAutoLayout), which is much more readable than the native one. When I wrote this series of methods, I didn't know about Masonry. After knowing about Masonry, I took a look and found that Masonry is indeed powerful. However, although this series of methods is not as powerful as Masonry, it is enough. At that time, the View layout of the Anjuke iPad version of the App was all done by Autolayout, which used the methods in this project. The readability is very good.

Allowing business engineers to use good tools to layout the View can improve their work efficiency and reduce the chance of bugs. Architects should not only care about those high-end content, but also provide business engineers with more convenient and easy-to-use tools to maximize the value of architects.

When to use storyboard, when to use nib, and when to write views in code

This issue is also mentioned in this article in Tang Qiao’s blog, and my opinion is basically the same as his.

#p#

I would like to add a few more things here:

iOS development with a certain scale (more than 10 people) has the following characteristics:

There are many authors for the same code file, and it is not uncommon for different authors to modify the same code at the same time. Therefore, the probability of conflicts when using Git for code version management is also relatively high.

Requirements change very frequently, and product managers often have to make minor adjustments to existing code to meet requirements, or partially reuse existing code.

There are many development tasks for complex interface elements and complex animation scenes.

If you understand these three characteristics at a glance, you don't need to read the following explanation. If you want to discuss my inclination further, you can read my explanation below first and then talk about it.

There are many authors for the same code file, and it is not uncommon for different authors to modify the same code at the same time. Therefore, the probability of conflicts when using Git for code version management is also relatively high.

During iOS development, you will encounter two most annoying conflicts: project.pbxproj and StoryBoard or XIB. The readability of these files is very poor. Although Apple has made some optimizations to the StoryBoard file description in XCode5 (I am not sure if it is this version), it only improves the readability from very poor to very poor.

However, StoryBoard often contains multiple pages, and it is basically impossible for one person to complete all of these pages. If another person, while operating StoryBoard, moves a page that does not belong to him for some purpose, such as adjusting the position for aesthetics. And another person also adjusts the position of another page in Storyboard because he wants to add a page. In this case, I can only say: Good luck. Look carefully, the specific page content has not been moved yet.

But if you use code to draw the View, Conflict will still occur, but this kind of Conflict is much easier to resolve, you know.

Requirements change very frequently, and product managers often have to make minor adjustments to existing code to meet requirements, or partially reuse existing code.

I think it's not the product manager's fault that he has an idea at the moment. He may be forced to do so. For example, everyone will get involved in the design of the product. Everyone in the company, from the CEO to the grassroots employees, may comment on the product design. As long as they are not satisfied with a certain aspect of the product (most likely personal preference) and happen to be familiar with the product manager and can talk to him, they will make various suggestions. The product manager can neither avoid nor provoke it. Sometimes there is nothing he can do, um.

But when it comes to engineers, this situation is very painful. Because sometimes the change is not only about the UI, but also the logic corresponding to the UI. The engineer will modify both files. The view you originally linked is no longer linked, and your corresponding outlets must also be deleted. If one of these two parts is not done, the App will crash after running it after compilation. It doesn't seem like a big deal, but it really affects your mood.

In addition, if some code is reused, for example, if you want to put a View on a page on another page, the related operation is not as simple as copying and pasting, you have to link it again, which also affects your mood.

There are many development tasks for complex interface elements and complex animation interaction scenes.

If you want to make an animation in a StoryBoard-based project, it is very annoying. It is also very annoying to make several complex interface elements. Sometimes we attach a Custom View, but it is actually a blank View in StoryBoard. Another point is that when your layout has problems and needs to be adjusted, it is still difficult to find the problem, especially in the case of complex interface elements.

So when it comes to the requirements of the View layer, I also recommend not using StoryBoard. It is just as easy to implement simple things with code, and it is easier to implement complex things with code than StoryBoard. So I advocate using code to draw views instead of storyboards.

Is it necessary for the business side to derive ViewController uniformly?

Sometimes, we derive our own ViewController from UIViewController to execute some common logic in order to record user operation behavior data or to unify the configuration page. For example, Tmall client requires all ViewControllers to inherit from TMViewController. This unified parent class has some settings for all life cycles of a ViewController. As for what settings are here, it is not important for this article. What I want to discuss here is, when designing the View architecture, if you want to achieve the purpose of unified settings or executing unified logic, is it necessary to use the method of derivation?

I don't think it's necessary. Why not?

Using derivation is more likely to increase the cost of use for the business side than not using derivation

The purpose of unified settings can be achieved without using derivative means

These two reasons are why I think it is unnecessary to use derivative means. If you understand both of them, then you don’t need to read the following. If you are still a little confused, please see below for me to explain the reasons in detail.

Why does the use cost for the business side increase when derivation is used?

In fact, not only the cost of use by the business side will increase, but also the maintenance cost of the architecture. So where does the specific cost come from?

Integration costs

The integration cost mentioned here is as follows: If the business party opens an independent demo and quickly completes a certain independent process, now he wants to integrate this existing process. Then the problem comes, he needs to change all independent UIViewControllers to TMViewController. So why not use TMViewController immediately from the beginning? Because if you want to introduce TMViewController, you have to introduce all the business lines and all the basic libraries of the entire Tmall App, because this parent class involves a lot of content that is only available in the Tmall environment. As the saying goes, if you want to simply inherit something, you will have to spend a lot of time setting up the environment before this small demo can run.

For all parent classes in the business layer, they are easily entangled with other codes in the project, which makes the business side face a dilemma when developing: either to deal with all dependencies and then develop a demo based on the App environment (such as Tmall), or to write their own demo and modify the code according to the environment requirements. Both dilemmas here will bring costs and affect the iteration progress of the business side.

I'm not sure if this situation will happen in your company, but I can give you a real example from my time at Alibaba: I've recently been developing a filter demo and related page flows, which will eventually be merged into the Tmall App. If you use the Tmall environment for development, it takes about 10 minutes to pod install all dependencies, and then after opening the workspace, you have to wait about another minute for Xcode to index before you can officially start working. I'd like to thank Zeping here, because he made a lot of optimizations on this basis, making this 1 minute much shorter than the original time. But if the Tmall environment is updated, you have to repeat the above process again, otherwise it is very likely that it will fail to compile.

Please, I just want to make a demo, I don't want to make it so complicated.

Acceptance cost

Sometimes new business engineers may not remember that every ViewController must be derived from TMViewController instead of directly from UIViewController. New engineers cannot just follow Apple's native approach to do things, they need to learn extra things, for example: all ViewControllers must inherit from TMViewController.

Difficulty in maintaining the architecture

Using inheritance as little as possible can improve the maintainability of the project. I have talked about the specific content in "Breaking Out of Object-Oriented Thinking (I) Inheritance". I don’t want to repeat what I said in that article here.

In fact, for the business side, the main problem is the first integration cost, which is a long-term pain that will occur every time you want to do something. The second point is not so bad, it is a short-term pain. The third point has nothing to do with business engineers.

So if we don't use derivation, what should we use?

My suggestion is to use AOP.

Before architects implement a specific solution, they must think through several issues before deciding which solution to adopt. What are these issues?

What is the effect of the plan and what is the ultimate goal?

Do you have the ability to implement this plan within your own knowledge system?

Among the existing open source components in the industry, are there any wheels that can be used directly?

After answering these three questions one by one in order, the specific plan can be obtained.

Let’s look at the first question first: What is the effect of the plan and what is the ultimate goal?

The effect of the program should be:

The business side does not need to use the inheritance method, and the framework can achieve unified configuration of ViewController.

Even if the business side leaves the framework environment, the code can be run without modifying any code. Once the business side's ViewController is thrown into the framework environment, the framework can play its role without modifying any code.

In fact, it is to achieve the function of allowing the business to be perceived by the framework without actively catering to the framework through business code. In detail, there are two problems: the framework must be able to intercept the life cycle of ViewController, and the other problem is the definition of the timing of interception.

For method interception, it is easy to think of Method Swizzling. Then we can write an example to add method interception for UIViewController when the App starts. This is one way. Another way is to use the load function of NSObject to automatically listen when the application starts. The advantage of using the latter is that this module can work as long as it is included in the project, without adding any code in the project.

Then another thing to consider is that the original TMViewController (the so-called parent class) will also provide additional methods for the convenience of subclasses. Method Swizzling only supports operations on existing methods. If you want to expand methods, well, of course, use Category.

I personally do not agree with the overuse of Category, but since Category is the most typical means of converting inheritance into composition, it is still suitable for use in this scenario. In addition, regarding the implementation of method interception by the method swizzling method, the industry already has a ready-made open source library: Aspects, which we can use directly.

I have a very small demo that I can show you. This demo is just a finishing touch. I have also written some words in this demo. Architects, you can expand it based on the needs of your company's App.

This demo does not include Category, after all, you still have to write Category yourself. Then this solution can complete all the tasks that can be completed by derivation, but at the same time allow the business party to use the native UIViewController directly without adding any code.

Another thing to remind you is that the purpose of this solution is to eliminate unnecessary inheritance. Although it is not limited to UIViewController, it also has a scope of application. Where inheritance is applicable, you should still use inheritance honestly. For example, if you have a data model that is a set of models derived from a basic model, then you should still use inheritance honestly. As for when to use inheritance, I believe that all architects will be able to handle it well, or you can refer to the article I mentioned earlier to control the scale of judgment.

A lot of ideas about MVC, MVVM, etc.

In fact, these are relatively common ideas. The three roles I mentioned in the opening are still the core: data manager, data processor, and data presenter. These various ideas are nothing more than formulating a specification that stipulates how these three roles should exchange data. But at the same time, these are also the most controversial topics, so I will sort out several mainstream ideas here so that you can have a better reference when you are working on the View layer architecture.

MVC

MVC (Model-View-Controller) is the oldest idea. It is so old that the Gang of Four classified it into a pattern in their book. Model is the data manager, View is the data displayer, and Controller is the data processor. Model and View are both deployed by Controller according to business needs, so Controller also has the function of data flow deployment. When I was writing this article, I saw this article published by InfoQ, which mentioned a pain point in mobile development: understanding the division of MVC architecture. I was unable to attend this symposium and could not express my personal opinion, so I can only write it here.

In the field of iOS development, how should we divide MVC?

There are actually two problems here:

Why do we get hung up on the MVC division issue in the field of iOS development?

In the field of iOS development, what is the correct way to divide?

Why do we get hung up on the MVC division issue in the field of iOS development?

Regarding this, everyone may have different concerns, and I don’t know what everyone’s opinions were at the forum. But please allow me to guess: Is it because UIViewController comes with a View and controls the entire life cycle of the View (viewDidLoad, viewWillAppear...), and we all know in common sense that the Controller should not have such a close connection with the View, so everyone is confused about the division? Below I will give my opinion on this guess.

In the server-side development field, the interaction between Controller and View is generally like this, such as Yii:

 /*
 ...
 Database data acquisition
 ...
 Processing Data
 ...
 */  
 // Here $this is the Controller  
 $ this ->render( "plan" ,array(
 'planList' => $planList,
 'plan_id' => $_GET[ 'id' ],
 ));

Here, the distinction between Controller and View is very clear. After the Controller has done its own work, it will hand over all the work related to View to the page rendering engine. The Controller will not do anything related to View, including generating View, which is done by the rendering engine. This is a difference, but in fact, the real difference between the concept of View on the server side and the concept of View on the Native application is that if we strictly divide the concepts, there is actually no View on the server side. Thanks to the HTTP protocol, the View we usually discuss is just a string used to describe the View (more substantially, it should be called data). The real View is the browser. .

Therefore, the server only generates the description of the View. As for the appearance of the View, UI event monitoring and processing, the browser is responsible for generating and maintaining it. However, from the Native side, the tasks that originally belonged to the browser cannot escape being done by itself. So who is the most suitable person to do this? Apple's answer is: UIViewController.

Given that Apple has made a lot of hard work in this layer, iOS engineers don't have to implement these contents themselves. Moreover, it puts all the functions on UIView, and makes UIView not only display UI, but also serve as a container object.

#p#

Do you understand what I mean by this? Another identity of UIView is actually a container! The view that comes with UIViewController, its main task is to act as a container. If all its related names are changed to ViewContainer, the code will become like this:

 - ( void )viewContainerDidLoad
 {
 [self.viewContainer addSubview:self.label];
 [self.viewContainer addSubview:self.tableView];
 [self.viewContainer addSubview:self.button];
 [self.viewContainer addSubview:self.textField];
 }
 ... ...

Just changed the name, does it feel much clearer now? If we want to explain it in more detail, the server-side MVC we usually think of is divided like this:

But in fact, the MVC division of the whole process is as follows:

As can be seen from the figure, under this concept, our server-side development actually only involves the development of M and C. The browser, as a container of View, is responsible for the display of View and the monitoring of events. Then corresponding to the MVC division of the iOS client, it is like this:

The only difference is that the View container is in the browser on the server side. In the entire website process, it is very reasonable to put this container in the browser. On the iOS client side, the View container is in the view of UIViewController. I also think that this choice made by Apple is very correct and wise.

Because the relationship between the browser and the server is very loose, and they belong to two different camps, the server will generate a description of the View and hand it over to the browser for display. However, once any event occurs on the view, it is rarely passed to the server (the so-called Controller) (it can also be passed: AJAX), and everything is done on the browser side. Therefore, in this case, the View container is suitable to be placed on the browser (V) side.

However, in the field of iOS development, although there are also ways to let View listen to events, this practice is very rare. Events are usually passed back to the Controller, and then the Controller makes separate arrangements. Therefore, it is very appropriate to place the View container in the Controller at this time. The Controller can easily change the container content due to different events. For example, when loading fails, the container content is replaced with the View of the failed page, and when there is no network, the container page is replaced with the View without network, etc.

In the field of iOS development, what is the correct approach to MVC division?

This question has actually been partially answered above, so the answer to this question can be regarded as a summary of the above questions.

What M should do:

Providing Data to ViewController

Provide an interface for ViewController to store data

Provides abstracted basic business components for Controller scheduling

What C should do:

Managing the View Container Lifecycle

Responsible for generating all View instances and placing them in the View Container

Listen to business-related events from View and complete the business of corresponding events through cooperation with Model.

What V should do:

Respond to events that are not related to the business, and thus trigger animation effects, click feedback (if appropriate, try to put it in the View as much as possible), etc.

Interface element expression

I answered these two questions by comparing with server MVC division. The reason I did this is because I know that many iOS engineers have transferred from the server side before. The same is true for me. Before entering Anjuke, I also did server development. During the process of learning iOS, I have also had doubts about the MVC division in the iOS field. The point I was puzzled about is the point I guessed at the beginning of the previous article. If someone asked me how to divide MVC in iOS, I would answer like the one above.

MVCS

Apple itself adopts this architecture, which can be seen from the name, and is also a set of architectures derived from MVC. Conceptually, the part it splits is the Model part, which splits out a Store. This Store is specifically responsible for data access. But from a practical perspective, it splits out a Controller.

This is a solution for thin Model. Thin Model is only used specifically to express data, and then storage and data processing are handed over to the outside world. The premise of using MVCS is that it assumes that you are thin Model, and the data storage and processing are done by the Controller. So corresponding to MVCS, it is a split controller from the beginning. Because the Controller does data storage, it will become very large, so the part that the Controller is specifically responsible for storing and retrieving data is extracted and handed over to another object to do, and this object is the Store. After this adjustment, the entire structure becomes a real MVCS.

About Fat Model and Slim Model

When I was interviewing and chatting with others, I found that not many people knew the concepts of fat Model and thin Model. About two or three years ago, the foreign industry had a very fierce discussion on this, and the topic was Fat Model and skinny controller. There are not many discussions on this aspect now, but until today, the industry has not yet concluded which one is better, fat Model or thin Model, so this is an unsolved controversy in the industry at present. I rarely see any information about this in China, so here I plan to add what fat Model is and what thin Model is. And where their debate comes from.

#p#

What is a fat model?

Fat Model contains some weak business logic. The goal of Fat Model is that after the Controller gets data from Fat Model, it can directly apply the data to the View without additional operations or as long as it does very few operations. For example:

 Raw Data:
 timestamp: 1234567  
 FatModel:
 @property (nonatomic, assign) CGFloat timestamp;
 - (NSString *)ymdDateString; // 2015-04-20 15:16  
 - (NSString *)gapString; // 3 minutes ago, 1 hour ago, one day ago, 2015-3-13 12:34  
 Controller:
 self.dateLabel.text = [FatModel ymdDateString];
 self.gapLabel.text = [FatModel gapString];

Convert timestamp into the string required for specific business, which belongs to the business code and is considered a weak business. After FatModel does these weak businesses, the Controller can become very skinny. The Controller only needs to pay attention to the strong business code. As we all know, the possibility of strong business changes is much greater than that of weak businesses. The weak business is relatively stable, so it is no problem to stuff the weak business into the Model. On the other hand, the frequency of weak business recurrence is greater than that of strong businesses, and the requirements for reuse are higher. If this part of the business is written in the Controller, similar codes will be spilled everywhere. Once the weak business is modified (the low frequency of weak business modification does not mean that there is no modification), this thing is a disaster. If it is stuffed into the Model, it can be modified in many places and can be avoided.

However, its disadvantage is that fat Model is relatively difficult to transplant. Although it only contains weak businesses, it is also a business after all. It is easy to pull out the carrots and bring out the mud during migration. Another point is that the architectural idea of ​​MVC is more inclined to be a Layer rather than an Object. What a Layer should do should not be left to an Object to do. Last point, software will grow, and FatModel is likely to become more and more Fat as the software grows, and it will eventually be difficult to maintain.

What is a thin model?

Thin Model is only responsible for the expression of business data, and all businesses, regardless of strength, are thrown into the Controller. The goal of Thin Model is to do everything possible to write fine-grained Models, and then use various helper classes or methods to abstract weak businesses. Strong businesses are still handed over to Controller. For example:

 Raw Data:
 {
 "name" : "casa" ,
 "sex" : "male" ,
 }
 SlimModel:
 @property (nonatomic, strong) NSString *name;
 @property (nonatomic, strong) NSString *sex;
 Helper:
 #define Male 1 ;
 #define Female 0 ;
 + (BOOL)sexWithString:(NSString *)sex;
 Controller:
 if ([Helper sexWithString:SlimModel.sex] == Male) {
 ...
 }

Since SlimModel has nothing to do with business, its data can be handed over to any Helper or other object that can process its data to complete the business. It is very independent during code migration, and it is rarely a situation where it is pulled out and brought out mud. In addition, since SlimModel is just a data expression, maintaining it is basically zero cost. No matter how powerful the software is, SlimModel will not be much larger.

The disadvantage is that Helper's approach is not necessarily very good. Here is an article criticizing this matter. In addition, since Model operations appear in various places, SlimModel violates the idea of ​​DRY (Don't Repeat Yourself) to a certain extent, and Controller still inevitably has code bloat to a certain extent.

My attitude? Well, I will say it in this section of the Heart Method of this Sect.

Speaking of which, MVCS is an architectural idea based on thin Model, abstracting part of the code about data storage among many things that Model originally had to do to the Store, which reduced the pressure on Controller to a certain extent.

MVVM

: : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : :

MVVM is based on the architectural concept of Fat Model, and then two parts are split out in Fat Model: Model and ViewModel. Regarding this point of view, I want to make an additional explanation: Fat Model does something to reduce the burden on the Controller first, and then disassemble the ViewModel because the Model becomes fat, which is not inconsistent with the statement that MVVM is essentially reducing the burden on the Controller, because Fat Model does something to reduce the burden on the Controller.

In addition, I said earlier that MVVM frees the task of data processing from the controller, which is not inconsistent with the splitting of the fat model by MVVM. To liberate the controller, you must first have a fat model, and then split the fat model into a Model and a ViewModel.

So how should MVVM be implemented?

This is very likely a problem that most people are struggling with. I plan to try to answer this question here based on my personal experience. Everyone is welcome to communicate in the comment area.

In the iOS field, most MVVM architectures use ReactiveCocoa, but are iOS applications using ReactiveCocoa based on MVVM architecture? Of course not. I think many people have this misunderstanding. Some people I interviewed mentioned ReactiveCocoa and also mentioned MVVM, but their understanding of this is so superficial that I can't help laughing. Well, in the network layer architecture, I will give examples of not using ReactiveCocoa, and it feels a bit early to give it a thumbs up.

The key to MVVM is to have a View Model! Instead of ReactiveCocoa (Errata 2)

What does ViewModel do? It is a model that turns RawData into an object that can be used directly by the View. For example:

 Raw Data:
 {
 (
 ( 123 , 456 ),
 ( 234 , 567 ),
 ( 345 , 678 )
 )
 }

Here we assume that the RawData is latitude and longitude, and I don't care too much about the numbers. Then you have a module that is a map module, converting all the latitude and longitude arrays into MKAnnotation or its derived classes is a weak business for the Controller (remember, fat Model is used to do weak business), so we use ViewModel to directly convert it into the NSArray of MKAnnotation, and after handing it to the Controller, the Controller can be used directly.

Well, this is what ViewModel needs to do. Do you think it is very simple and you can't see superiority?

Anjuke Pad application also has a map module. Here I designed an object called reformer (actually ViewModel), which is specifically used to do this. So where is the advantage of doing this?

Anjuke is divided into three major businesses: renting, second-hand houses, and new houses. These three businesses correspond to the mobile development team. They each do their own business, which leads to a result: Although the data contents returned by the three API teams to the mobile client are consistent, the data formats are inconsistent, that is, the keys corresponding to the same value are inconsistent. However, the ViewController that displays the map cannot write three, so there must be a logic for API data compatibility. I put this logic in the reformer, so the business process becomes like this:

In this way, the originally complex MKAnnotation assembly logic is split from the Controller, and the Controller can directly display the data returned by the Reformer. APIManager belongs to the Model, and reformer belongs to the ViewModel. I will explain the specific details about reformer in the network layer architecture for detailed explanation. The ViewModel role played by Reformer at this time can greatly reduce the burden on the Controller, and the maintenance cost is also greatly reduced. After the reformer, the MKAnnotation will always be produced, and the Controller can be used directly.

Then another point is that there is another business requirement to take nearby housing sources. The map API request can hold this requirement, so there is no need to change other places. Just change a reformer when fetchDataWithReformer, and leave the other things to the reformer.

So what role should ReactiveCocoa play?

You can MVVM without using ReactiveCocoa. ReactiveCocoa can better reflect the essence of MVVM. The example I mentioned earlier is just the direction of data from API to View. View operations will also generate "data", but the "data" here is more reflected in the operation of expressing users. For example, what content is input, then the data is text, which cell is selected, and then the data is indexPath. Then, in the direction of data from view to API or controller, it is where ReactiveCocoa plays.

We know that ViewModel is essentially a Model layer (because it is part of the fat Model), so View is not suitable to directly hold ViewModel. So what should I do if the View generates data? Throw the signal to the ViewModel, who will throw it? ReactiveCocoa.

The first purpose of using ReactiveCocoa in MVVM is that as mentioned above, View is not suitable for directly holding ViewModel. The second purpose is that ViewModel may not only serve a specific View, and using a looser binding relationship can reduce the coupling degree between ViewModel and View.

So what role does Controller play in MVVM?

Most domestic and foreign data explain MVVMs in this way: View <-> ViewModel <-> Model, which has caused the illusion that MVVM does not need a controller. Now it seems that MVVM begins to appear in the industry that MVVM does not need a controller. . In fact, MVVM must require the participation of controllers. Although MVVM weakens the presence of controllers to a certain extent and reduces the burden and loses weight for controllers (this is also the main purpose of MVVM). However, this does not mean that controllers are not needed in MVVM. The relationship between MMVC and MVVM should be like this:

View <-> C <-> ViewModel <-> Model, so after using MVVM, the statement that there is no need for a controller is incorrect. Strictly speaking, MVVM is actually an MVCVM. From the figure, we can see that one of the main things that the Controller does between the View and the ViewModel is to bind the View and the ViewModel. Logically, the Controller knows which ViewModel should be displayed, and the Controller also knows which ViewModel should be used. However, the View and ViewModel do not know each other, so the Controller is responsible for controlling their binding relationship, so this is why it is called Controller/controller.

I have talked so much about it before, but in the end it is just one sentence: on the basis of MVC, detach C a ViewModel specifically responsible for data processing, which is MVVM. Then, in order to have a relatively loose binding relationship between View and ViewModel, we use ReactiveCocoa because Apple itself does not provide a binding method that is more suitable for this situation. In the iOS field, KVO, Notification, block, delegate and target-action can all be used for data communication to achieve binding, but they are not as elegant as RACSignal provided by ReactiveCocoa. If ReactiveCocoa is not used, the binding relationship may not be as loose and good, but it does not affect that it is still MVVM.

In the actual iOS application architecture, MVVM should appear in the iOS application architecture diagram of most startups or established companies' new apps. As far as I know, a certain iOS application under Yibao Payment adopts the MVVM architecture as a whole. They extracted an Action layer to install various ViewModels, which is also a relatively reasonable structure.

Therefore, in MVVM, the Controller is responsible for the binding between View and ViewModel, and on the other hand, it is also responsible for the regular UI logic processing.

#p#

VIPER

VIPER (View, Interactor, Presenter, Entity, Routing). I haven't actually used VIPER, I saw it in issue 13 on objc.io.

Whenever a new architecture appears or a new architecture I was not familiar with before, I can be very sure that this guy must have dismantled the MVC part (bad smirk, I have already talked about the theoretical basis for making this judgment in the first article). The fact is that VIPER has indeed dismantled a lot, except for the View not dismantled, everything else has been dismantled.

The two articles I mentioned are very detailed about VIPER and you can understand it at a glance. But I am not very clear about the pitfalls or controversies when using VIPER. If I insist on writing this section, I can only rely on YY, so I will forget it. If anyone who uses VIPER architecture in the actual App or is very interested in VIPER, you can put it in the comment section and let's communicate.

This method of mind

A heavy sword without a sharp edge, and a great trick is not skillful. --- "The Legend of Condor Heroes"

This is a passage written next to the Xuan Iron Heavy Sword when Yang Guo was picking a sword. I deeply agree with this. The purpose of mentioning this passage is to tell everyone that when designing the View layer architecture, you don’t need to stick to the rules such as MVC, MVVM, VIPER, etc. These are all moves. You will know, and then you can play it no matter how you play it. But the mental method is not like this. The mental method is a great trick, and it is very simple to say it, but whether you can keep the mental method in mind when designing the actual architecture and do things according to the rules depends on the individual.

The mind method of splitting

Shaolin is produced in the world, and MVC is formed in the world. --- Casa Taloyum

MVC is actually a very high-level abstraction, which means that under the MVC system, countless architectural methods can be derived, but what changes are the same is that it must comply with the specifications of MVC. This sentence is not what I said, but I saw it on some English material, but I can no longer find the source. I agree with this sentence. The architecture I use is strictly MVC, but it has also done a lot of splitting. According to the baptism in the previous sections, I believe you also understand this truth: different splitting methods have given birth to various derivative architecture solutions (MVCS breaking the fat controller, MVVM breaking the fat model, VIPER breaking everything), but no matter how diverse the splitting methods are, it is just a move. The splitting specification is the mental method. In this section, I will talk about the mental method of splitting when I do the View architecture.

The first method: retain the most important tasks and split other unimportant tasks

In the iOS development field, UIViewController carries a lot of things, such as View initialization, business logic, event response, data processing, etc. Of course, there are more I can't list now, but we know that there is one thing that Controller must not escape: Coordinate V and M. That is to say, no matter how it is disassembled, coordination work cannot be disassembled.

Then we can disassemble the rest, such as the DataSource of UITableView. Tang Qiao's blog has an article mentioning that he and another engineer have been arguing about whether to split DataSource for a long time. Splitting DataSource should be considered a general practice. In uncomplexing applications, it may indeed look like an array, but in complex situations, it may involve complex logic such as file content reading, data synchronization, etc. The first section of this article advocates this practice, and I actually advocate it quite well.

The previous article also mentioned a lot of things that can be disassembled, so I won't move them. You can go in and take a look. In addition to the content mentioned in this article, any larger ones that are dirty in the ViewController can be considered as disassembly as long as they are not the core logic of the Controller, and then they can be defined as an independent module when the architecture is used, and designed to implement them.

The second method: the split module should improve reusability as much as possible and try to achieve DRY

Things that are separated according to the first mind method are very likely to be strong business-related, and this situation is sometimes unavoidable. But we should also dismantle them well. It is best to classify the part that is dismantled into a certain type of object, and then it is best to abstract a general logic so that it can be reused. Even if the general logic cannot be extracted, try to abstract a protocol to realize the IOP. There is an article about IOP here, and you will understand the superiority after reading it.

The third method: to improve the abstraction after splitting the module as much as possible

In other words, the granularity of the split should be as large as possible and the encapsulation should be transparent. Tang Qiao said that all hiding is an increase in code complexity unless it brings benefits, which makes some sense to a certain extent. Hiding without benefits is indeed not good (laugh). In fact, increasing the degree of abstraction is to increase the intensity of encapsulation, abstracting a responsible business into a very small input, which is highly abstract. Well, inheriting many layers, although this practice also increases the degree of abstraction, I do not recommend playing this way. I am not sure whether the hiding that Tang Qiao mentioned here is the same concept as the encapsulation I mentioned, but what I want to advocate here is to increase the degree of abstraction as much as possible.

The advantage of improving the degree of abstraction is that for the business party, they only need to collect very little information (minimum required conditions) and do very little scheduling (the Controller is responsible for scheduling large modules, and then do scheduling small modules in large modules) to complete the task. This is the correct way to reduce the burden on the Controller.

If the split module is not abstract enough and the module requires more parameters to the outside world, then there will be a lot more code for collecting parameters in the Controller. If the collection logic of some parameters can be completed by the module, it can also help the Controller reduce the burden. Otherwise, it will feel that the disassembly is not clean, because there are still some unnecessary parameter collection logic in the Controller.

If the split granularity is too small, it is not good to write a lot of scheduling code when completing the task. The primary factor that leads to a small split granularity is that the business may be relatively complex itself. It is not bad to have a small split granularity. If it can be larger, it is no problem. For handling this situation, the strategy mode is needed.

In view of the small split granularity, let me give you a practical example. This example comes from a friend of mine who is working on the message sending module of a chat application. When the message is text, it is sent directly. When the message is a picture, you need to apply to the server for uploading resources, obtain the resource ID and then upload the image. After uploading the image, you will get the image URL, and then send the information with the URL.

At this time, we can split the module into: data sending (called module A), uploading resource application (called module B), and uploading content (called module C). Then, if you want to send text messages, the Controller dispatches A. If you want to send image messages, the Controller dispatches B->C->A. If you want to upload other types of messages in the future, and they will rely on the D/E/F module, then this matter is very painful, because the logic is complicated, and there are more things that the Controller needs to schedule to differentiate, and the Controller expands.

So how to deal with it? You can use Strategy mode. Let's analyze again. What are the conditions that the Controller has in the initial situation? It has all the data of this message and also knows the type of this message. So what does it ultimately need? The result of message sending: sending successfully or fails.

The above is the final result we want to achieve. The Controller just throws the message to the MessageSender, and then lets the MessageSender do things. Just tell the Controller after doing it. So how do you schedule the logic in the MessageSender? There can be a StrategyList in the MessageSender, which stores blocks or Invocations (Target-Actions) that express various logics. Then we first define an Enum, which specifies the scheduling logic required for each task.

 typedef NS_ENUM (NSUInteger, MessageSendStrategy)
 {
 MessageSendStrategyText = 0 ,
 MessageSendStrategyImage = 1 ,
 MessageSendStrategyVoice = 2 ,
 MessageSendStrategyVideo = 3  
 } 
 
 Then the StrategyList in the MessageSender is like this:

 @property (nonatomi, strong) NSArray *strategyList;
 self.strategyList = @[TextSenderInvocation, ImageSenderInvocation, VoiceSenderInvocation, VideoSenderInvocation];
 // Then provide an interface like this to the outside, and there is a delegate to callback  
 - ( void )sendMessage:(BaseMessage *)message withStrategy:(MessageSendStrategy)strategy;
 @property (nonatomic, weak) id<messagesenderdelegate> delegate;
 @protocol MessageSenderDelegate<nsobject>
 @required  
 - ( void )messageSender:(MessageSender *)messageSender
 didSuccessSendMessage:(BaseMessage *)message
 strategy:(MessageSendStrategy)strategy;
 - ( void )messageSender:(MessageSender *)messageSender
 didFailSendMessage:(BaseMessage *)message
 strategy:(MessageSendStrategy)strategy
 error:(NSError *)error;
 @end </nsobject></messagesenderdelegate> 
 
 This is how the Controller is used:
 1   
 
 [self.messageSender sendMessage:message withStrategy:MessageSendStrategyText]; 
 
 MessageSender is like this:
 1   
 
 [self.strategyList[strategy] invoke]; 
 
 Then in an Invocation, it's like this:
 1  
 2  
 3   
 
 [A invoke];
 [B invoke];
 [C invoke];

That's fine. Even if the split granularity cannot be refined due to objective reasons, it can extract the complex judgment logic and scheduling logic from the controller, and truly reduce the burden on the controller. In short, if you can achieve a large granularity, try to achieve a large granularity. If you really can't do it, you can hold it with Strategy. This example is a small granularity situation. The large granularity situation is too simple, so I won't mention it.

Design mind method

The architecture for the View layer not only focuses on how to reasonably split MVC to reduce the burden on the UIViewController, but also takes into account the cost of the business. The best situation is that the business party doesn't know anything, and then he can run it by putting the code in, and at the same time he can obtain various functions provided by the framework.

For example, the audience stands on Tiananmen Square are the best designs I think, because no one will notice it.

The first method: minimize the inheritance level and try not to inherit if it involves Apple native objects.

: : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : :

It may not be so intuitive in terms of thinking without inheritance, but the benefits of not using inheritance are enough to match the disadvantages of using inheritance. By the way, I want to give Category a clear name: the industry's attitude towards Category is relatively ambiguous, and it has been advocated to try not to use Category in many occasions (lectures, materials and documents). What they say makes sense, but I think Category is the best solution provided by Apple to use collections instead of inheritance, but the design for Category also has high requirements for architects, please use it reasonably. Moreover, Apple also uses Category in many occasions to split an object that may be large into different Category according to different scenarios, thereby improving maintainability.

I have already mentioned the benefits of not using inheritance here. In terms of the iOS application architecture, there are two additional benefits: 1. When the business party is doing business development or demo, you can leave the App environment or spend less time building the environment. 2. For the business party, the functions are more transparent and also in line with the business party’s first intuition during development.

The second method: make good code specifications and specify the layout of the code in the file, especially the ViewController

This is mainly to improve maintainability. In an object with a very large file, it is especially necessary to limit the layout of different types of code in the file. For example, when writing a ViewController, the specification I set for the team before is that the first paragraph is all getter setters, and the next paragraph is life cycle, viewDidLoad and other methods are all here. Then the next paragraph is the various Delegates to be implemented, and the next paragraph is the event response, button or GestureRecognizer are all here. Then the next paragraph is the private method. Generally speaking, if the split is done, there is no method in the private method of ViewController. Later, as time goes by, I found that putting getters and setters at the beginning affects reading, so I changed it to put them all at the end of ViewController.

The third method: try not to put what the controller does.

The reason why Controllers become huge is, on the one hand, because the Controller carries business logic. The summaries of MVC (before the formal proposal of MVC, there were more or less people design it like this, so the designer of MVC is not very accurate) also carries business logic. Therefore, Controller is used to do this, which is natural. On the other hand, because in MVC, the definitions of Model and View are very clear, and few people will put something that belongs to M or V elsewhere. Then, in addition to Model and View, there are many ambiguous things left. These things are conceptually considered Controllers, and since M and V are so clearly defined, it is intuitive that these things are inappropriate to put them in M ​​or V, so they plug into the Controller.

It is precisely because of the above two reasons that the Controller has expanded. Let’s think about it carefully. It is relatively easy to split the Model and View. After the Controller expands, splitting will be extremely difficult. So if you can try to put what you can do elsewhere at the beginning, so that your part of the code that may be split in the future can be kept away from business logic at the first time. So we need to change our thinking a little: don’t stuff the ambiguous modules. It is better to stuff V or M or anything else than stuff the Controller, making it easier to split in the future.

So regarding the choices of fat Model and thin Model that I pressed before, my attitude is more inclined to fat Model. Objectively speaking, after business expansion, the code scale is definitely indispensable. No matter how good your technology is or rich experience, the amount of code can only be optimized at most. The expansion will still be expanded. Moreover, the code is often ugly after optimization, and using various tricks and tricks also comes at a cost. Therefore, the results of optimization for code volume often sacrifice readability or portability (genericity). Every magic always needs a pay, you have to make a trade-off.

So since the expanded code or the code that may be expanded in the future, no matter which part of the MVC is placed, it will be split in the end. Since it will be split sooner or later, it is better to put it in the Model, so that it will be easier to split the fat Model in the future than to split the fat Cotroller. When I was still in Anjuke, the ViewController that the Anjuke Pad app carries the most complex business was less than 600 lines, and most other controllers were between 300-400 lines, which reduced the difficulty of getting started and maintenance complexity for those who took over the latter. The split items can be directly migrated to iPhone apps. Now looking at the ViewController on Tmall, there are thousands of lines at every turn, and I can't see it for a long time and I feel dizzy. After asking, everyone said that they are very accustomed to such code lengths and spread their hands.

The fourth method: Architects serve business engineers, not business engineers

The rank and status of an architect in the company are often higher than that of a business engineer, and the technical strength and experience of an architect are often higher than that of a business engineer. Therefore, you deserve to gain a higher position in the company, but a high position in the company does not mean that he has a high role in software engineering. Architects must serve business engineers, and they are the ones who command you rather than you command them. In addition, formulating specifications is one that restricts the code of a business engineer, but more importantly, this is actually to use your ability to help a business engineer avoid crises that he cannot foresee, so a high status has certain benefits. After all, summer insects cannot be spoken of, and sometimes it may not be explained. Therefore, what comes with high status is that they are more persuasive. But in software engineering, you must be humble and must consider more for business engineers.

An architect who doesn't understand this principle is often complicated and difficult to use because he is only willing to do the core things, and he hopes to leave them to the business engineers for doing what he doesn't want to do. Sometimes he just makes a demo and then gives them to the business engineers. The business engineer becomes a job for him. However, an architect who understands this principle will design things very useful. The business party only needs to throw away few parameters and get the results. Such an architecture is called a good architecture.

To give an example of saving images to local, one way is to provide an interface like this: - (NSString *)saveImageWithData:(NSData *)imageData, and the other is - (NSString *)saveImage:(UIImage *)image. The latter is better, the reason you think about it yourself.

The humbler your attitude, the better you can design a good architecture. This is the last and most important thing in my design mindset. Even if your technical strength is not at the level of a big shot in the industry, as long as you maintain this mentality and do the design, you are already a qualified architect, and it will be very fast to become a big shot in the industry.

#p#

A brief summary

In fact, there are still three things to do in the architectural design of the View layer: code specifications, architecture patterns, and tool sets.

Code specifications are of great significance to the View layer. After all, the View layer is very business-oriented. If the code layout is chaotic, it will be difficult for latecomers to take over and maintain.

The specific choice of the architecture model depends entirely on the complexity of the business. If the business is quite complex, then you can use VIPER. If it is relatively simple, just change it slightly. Each architecture model that has become a fixed pattern may not be suitable for the corresponding business of each company, so the architects need to do some splits or changes according to the situation. There is generally no problem with splitting. When changing, just don’t mess up the three roles of MVC. Do whatever M should do, C should do whatever V should do, and don’t do anything randomly. This article has already mentioned what most architecture models should look like, but I think the most important thing is the mental method later. The model is just a trick. Only by familiarizing yourself with the mental method can you be very tricks.

The view layer tool set mainly focuses on how to layout the View, as well as some specific Views, such as the search box with search prompts. This article only mentions the tool set for view layout. Other tools sets are relatively more dependent on the business of their respective companies. It is not difficult to implement or use ready-made CocoaPods.

For small-scale or medium-sized iOS development teams, it is enough to do the above three points well. In large-scale teams, there is an additional problem to consider, which is the design of cross-business page call schemes.

Design of cross-business page call scheme

Cross-business page call means that when there are multiple services such as A, B, etc. in an App, B may need to display a page of A, and A may also call a page of other services. In a small-scale app, we will directly import a ViewController of other services and then push or present, which will not cause a particularly big problem. However, if the app is very large and involves a lot of services, then importing it directly will cause problems.

It can be seen that cross-service page calls in apps composed of multiple services will lead to horizontal dependence. So what will happen if you don’t try to solve horizontal dependence like this?

当一个需求需要多业务合作开发时，如果直接依赖，会导致某些依赖层上端的业务工程师在前期空转，依赖层下端的工程师任务繁重，而整个需求完成的速度会变慢，影响的是团队开发迭代速度。

当要开辟一个新业务时，如果已有各业务间直接依赖，新业务又依赖某个旧业务，就导致新业务的开发环境搭建困难，因为必须要把所有相关业务都塞入开发环境，新业务才能进行开发。影响的是新业务的响应速度。

当某一个被其他业务依赖的页面有所修改时，比如改名，涉及到的修改面就会特别大。影响的是造成任务量和维护成本都上升的结果。

当然，如果App规模特别小，这三点带来的影响也会特别小，但是在阿里这样大规模的团队中，像天猫／淘宝这样大规模的App，一旦遇上这里面哪怕其中一件事情，就特么很坑爹。

那么应该怎样处理这个问题？

让依赖关系下沉。

怎么让依赖关系下沉？引入Mediator模式。

所谓引入Mediator模式来让依赖关系下沉，实质上就是每次呼唤页面的时候，通过一个中间人来召唤另外一个页面，这样只要每个业务依赖这个中间人就可以了，中间人的角色就可以放在业务层的下面一层，这就是依赖关系下沉。

当A业务需要调用B业务的某个页面的时候，将请求交给Mediater，然后由Mediater通过某种手段获取到B业务页面的实例，交还给A就行了。在具体实现这个机制的过程中，有以下几个问题需要解决：

设计一套通用的请求机制，请求机制需要跟业务剥离，使得不同业务的页面请求都能够被Mediater处理

设计Mediater根据请求如何获取其他业务的机制，Mediater需要知道如何处理请求，上哪儿去找到需要的页面

这个看起来就非常像我们web开发时候的URL机制，发送一个Get或Post请求，CGI调用脚本把请求分发给某个Controller下的某个Action，然后返回HTML字符串到浏览器去解析。苹果本身也实现了一套跨App调用机制，它也是基于URL机制来运转的，只不过它想要解决的问题是跨App的数据交流和页面调用，我们想要解决的问题是降低各业务的耦合度。

不过我们还不能直接使用苹果原生的这套机制，因为这套机制不能够返回对象实例。而我们希望能够拿到对象实例，这样不光可以做跨业务页面调用，也可以做跨业务的功能调用。另外，我们又希望我们的Mediater也能够跟苹果原生的跨App调用兼容，这样就又能帮业务方省掉一部分开发量。

就我目前所知道的情况，AutoCad旗下某款iOS应用（时间有点久我不记得是哪款应用了，如果你是AutoCad的iOS开发，可以在评论区补充一下。）就采用了这种页面调用方式。天猫里面目前也在使用这套机制，只是这一块由于历史原因存在新老版本混用的情况，因此暂时还没能够很好地发挥应有的作用。

嗯，想问我要Demo的同学，我可以很大方地告诉你，没有。不过我打算抽时间写一个出来，现在除了已经想好名字叫Summon以外，其它什么都没做，哈哈。

关于Getter和Setter？

我比较习惯一个对象的"私有"属性写在extension里面，然后这些属性的初始化全部放在getter里面做，在init和dealloc之外，是不会出现任何类似_property这样的写法的。就是这样：

 @interface CustomObject()
 @property (nonatomic, strong) UILabel *label;
 @end  
 @implement  
 #pragma mark - life cycle
 - ( void )viewDidLoad
 {
 [ super viewDidLoad];
 [self.view addSubview:self.label];
 }
 - ( void )viewWillAppear:(BOOL)animated
 {
 [ super viewWillAppear:animated];
 self.label.frame = CGRectMake( 1 , 2 , 3 , 4 );
 }
 #pragma mark - getters and setters
 - (UILabel *)label
 {
 if (_label == nil) {
 _label = [[UILabel alloc] init];
 _label.text = @ "1234" ;
 _label.font = [UIFont systemFontOfSize: 12 ];
 ... ...
 }
 return _label;
 }
 @end  

唐巧说他喜欢的做法是用_property这种，然后关于_property的初始化通过[self setupProperty]这种做法去做。从刚才上面的代码来看，就是要在viewDidLoad里面多调用一个setup方法而已，然后我推荐的方法就是不用多调一个setup方法，直接走getter。

嗯，怎么说呢，其实两种做法都能完成需求。但是从另一个角度看，苹果之所以选择让[self getProperty]和self.property可以互相通用，这种做法已经很明显地表达了苹果的倾向：希望每个property都是通过getter方法来获得。

早在2003年，Allen Holub就发了篇文章《Why getter and setter methods are evil》，自此之后，业界就对此产生了各种争议，虽然是从Java开始说的，但是发展到后面各种语言也参与了进来。然后虽然现在关于这个问题讨论得少了，但是依旧属于没有定论的状态。setter的情况比较复杂，也不是我这一节的重点，我这边还是主要说getter。我们从objc的设计来看，苹果的设计者更加倾向于getter is not evil。

认为getter is evil的原因有非常之多，或大或小，随着争论的进行，大家慢慢就聚焦到这样的一个原因：Getter和Setter提供了一个能让外部修改对象内部数据的方式，这是evil的，正常情况下，一个对象自己私有的变量应该是只有自己关心。

然后我们回到iOS领域来，objc也同样面临了这样的问题，甚至更加严重：objc并没有像Java那么严格的私有概念。但在实际工作中，我们不太会去操作头文件里面没有的变量，这是从规范上就被禁止的。

认为getter is not evil的原因也可以聚焦到一个：高度的封装性。getter事实上是工厂方法，有了getter之后，业务逻辑可以更加专注于调用，而不必担心当前变量是否可用。我们可以想一下，假设一个ViewController有20个subview要加入view中，这20个subview的初始化代码是肯定逃不掉的，放在哪里比较好？放在哪里都比放在addsubview的地方好，我个人认为最好的地方还是放在getter里面，结合单例模式之后，代码会非常整齐，生产的地方和使用的地方得到了很好的区分。

所以放到iOS来说，我还是觉得使用getter会比较好，因为evil的地方在iOS这边基本都避免了，not evil的地方都能享受到，还是不错的。

Summarize

要做一个View层架构，主要就是从以下三方面入手：

制定良好的规范

选择好合适的模式（MVC、MVCS、MVVM、VIPER）

根据业务情况针对ViewController做好拆分，提供一些小工具方便开发

当然，你还会遇到其他的很多问题，这时候你可以参考这篇文章里提出的心法，在后面提到的跨业务页面调用方案的设计中，你也能够看到我的一些心法的影子。

对于iOS客户端来说，它并不像其他语言诸如Python、PHP他们有那么多的非官方通用框架。客观原因在于，苹果已经为我们做了非常多的事情，做了很多的努力。在苹果已经做了这么多事情的基础上，架构师要做针对View层的方案时，最好还是尽量遵守苹果已有的规范和设计思想，然后根据自己过去开发iOS时的经验，尽可能给业务方在开发业务时减负，提高业务代码的可维护性，就是View层架构方案的最大目标。

2015-04-28 09:28补：关于AOP

AOP（Aspect Oriented Programming），面向切片编程，这也是面向XX编程系列术语之一哈，但它跟我们熟知的面向对象编程没什么关系。

什么是切片？

程序要完成一件事情，一定会有一些步骤，1，2，3，4这样。这里分解出来的每一个步骤我们可以认为是一个切片。

什么是面向切片编程？

你针对每一个切片的间隙，塞一些代码进去，在程序正常进行1，2，3，4步的间隙可以跑到你塞进去的代码，那么你写这些代码就是面向切片编程。

为什么会出现面向切片编程？

你要想做到在每一个步骤中间做你自己的事情，不用AOP也一样可以达到目的，直接往步骤之间塞代码就好了。但是事实情况往往很复杂，直接把代码塞进去，主要问题就在于：塞进去的代码很有可能是跟原业务无关的代码，在同一份代码文件里面掺杂多种业务，这会带来业务间耦合。为了降低这种耦合度，我们引入了AOP。

如何实现AOP？

AOP一般都是需要有一个拦截器，然后在每一个切片运行之前和运行之后（或者任何你希望的地方），通过调用拦截器的方法来把这个jointpoint扔到外面，在外面获得这个jointpoint的时候，执行相应的代码。

在iOS开发领域，objective-C的runtime有提供了一系列的方法，能够让我们拦截到某个方法的调用，来实现拦截器的功能，这种手段我们称为Method Swizzling。Aspects通过这个手段实现了针对某个类和某个实例中方法的拦截。

另外，也可以使用protocol的方式来实现拦截器的功能，具体实现方案就是这样：

 @protocol RTAPIManagerInterceptor <nsobject>
 @optional  
 - ( void )manager:(RTAPIBaseManager *)manager beforePerformSuccessWithResponse:(AIFURLResponse *)response;
 - ( void )manager:(RTAPIBaseManager *)manager afterPerformSuccessWithResponse:(AIFURLResponse *)response;
 - ( void )manager:(RTAPIBaseManager *)manager beforePerformFailWithResponse:(AIFURLResponse *)response;
 - ( void )manager:(RTAPIBaseManager *)manager afterPerformFailWithResponse:(AIFURLResponse *)response;
 - (BOOL)manager:(RTAPIBaseManager *)manager shouldCallAPIWithParams:(NSDictionary *)params;
 - ( void )manager:(RTAPIBaseManager *)manager afterCallingAPIWithParams:(NSDictionary *)params;
 @end  
 @interface RTAPIBaseManager : NSObject
 @property (nonatomic, weak) id<rtapimanagerinterceptor> interceptor;
 @end </rtapimanagerinterceptor></nsobject>

这么做对比Method Swizzling有个额外好处就是，你可以通过拦截器来给拦截器的实现者提供更多的信息，便于外部实现更加了解当前切片的情况。另外，你还可以更精细地对切片进行划分。Method Swizzling的切片粒度是函数粒度的，自己实现的拦截器的切片粒度可以比函数更小，更加精细。

缺点就是，你得自己在每一个插入点把调用拦截器方法的代码写上（笑），通过Aspects（本质上就是Mehtod Swizzling）来实现的AOP，就能轻松一些。

2015-4-29 14:25 补：关于在哪儿写Constraints？

文章发出来之后，很多人针对勘误1有很多看法，以至于我觉得很有必要在这里做一份补。期间过程很多很复杂，这篇文章也已经很长了，我就直接说结果了哈。

苹果在文档中指出，updateViewConstraints是用来做add constraints的地方。

但是在这里有一个回答者说updateViewConstraints并不适合做添加Constraints的事情。

综合我自己和评论区各位关心这个问题的兄弟们的各种测试和各种文档，我现在觉得还是在viewDidLoad里面开一个layoutPageSubviews的方法，然后在这个里面创建Constraints并添加，会比较好。就是像下面这样：

 - ( void )viewDidLoad
 {
 [ super viewDidLoad];
 [self.view addSubview:self.firstView];
 [self.view addSubview:self.secondView];
 [self.view addSubview:self.thirdView];
 [self layoutPageSubviews];
 }
 - ( void )layoutPageSubviews
 {
 [self.view addConstraints:xxxConstraints];
 [self.view addConstraints:yyyConstraints];
 [self.view addConstraints:zzzConstraints];
 }

最后，要感谢评论区各位关心这个问题，并提出自己意见，甚至是自己亲自测试然后告诉我结果的各位兄弟：@fly2never，@Wythe，@wtlucky，@lcddhr，@李新星，@Meigan Fang，@匿名，@Xiao Moch。

这个做法是目前我自己觉得可能比较合适的做法，当然也欢迎其他同学继续拿出自己的看法，我们来讨论。

Errata

我的前同事@ddaajing看了这篇文章之后，给我提出了以下两个勘误，和很多行文上的问题。在这里我对他表示非常感谢：

勘误1：其实在viewWillAppear这里改变UI元素不是很可靠，Autolayout发生在viewWillAppear之后，严格来说这里通常不做视图位置的修改，而用来更新Form数据。改变位置可以放在viewWilllayoutSubview或者didLayoutSubview里，而且在viewDidLayoutSubview确定UI位置关系之后设置autoLayout比较稳妥。另外，viewWillAppear在每次页面即将显示都会调用，viewWillLayoutSubviews虽然在lifeCycle里调用顺序在viewWillAppear之后，但是只有在页面元素需要调整时才会调用，避免了Constraints的重复添加。

勘误2：MVVM要有ViewModel，以及ReactiveCocoa带来的信号通知效果，在ReactiveCocoa里就是RAC等相关宏来实现。另外，使用ReactiveCocoa能够比较优雅地实现MVVM模式，就是因为有RAC等相关宏的存在。就像它的名字一样Reactive-响应式，这也是区分MVVM的VM和MVC的C和MVP的P的一个重要方面。

本文遵守CC-BY。 请保持转载后文章内容的完整，以及文章出处。本人保留所有版权相关权利。