iOS Dev > Learning-use MVC mode to help Viewcontroller slim

As the complexity of the program logic increases, do you also find that some viewcontroller in the app have a sharp increase in the number of lines of code, reaching 2, 3,000 lines, or more. This can be a headache if you want to add a little bit of functionality or modify existing logic. If you're having this kind of problem, it's time to stop and think about how to better organize the code and lean on the VC. This article will explain how to combine the ideas of MVC to help your VC lean while improving reuse and scalability.

first, the development of common phenomena and shortcomings

One of the most common design patterns in iOS is MVC, but in the actual development process, we make simple viewcontroller into a collection of Model,controller and a large set of view, for one reason or another. This will inevitably lead to VC code capacity is geometric growth. There are several issues with this code:

1, not conducive to follow-up maintenance

The code in a company's survival time is usually much longer than you in the company's time, you are also taking over the existing project, while looking at the code side in the heart meditation "a piece of shit", I think no one hope to take over your code one day when the people look at your code in the heart of the same words. As a pursuit of the programmer, or in order not to be scolded by future colleagues, we must be responsible for their own code, avoid a thousands of line of a source file. You don't want to look at your own writing, let alone the successor.

If the project is in a hurry, there is no time for reasonable splitting and refactoring of the code, follow-up must also spare time to fill out the pit of their own digging. You might say that the company has been very busy with no time left for you to refactor. I can only say that you will not be able to arrange the time, or the company only put you as a code porter. From a long-term perspective, either change yourself or fire the boss.

2, not conducive to support the changes in the UI

Imagine if one day your app's UI style needs to change, a lot of view needs to change, in a thousands of-line VC to delete the change is what feeling. May be because of changes in the UI when a mistake to change the model or controller things, causing the program will not work properly. And the scope of the changes can not be controlled in a small scope, testing the return of the workload is also very large.

3, not conducive to reuse

If your app only supports the iphone version at first, everything is natural and the program works well. Suddenly one day the boss told you that the company's business development is good, in order to expand the market need to exit the ipad version, this time if only the iphone version of the larger version, then you need to do is to add some of the view of the adaptive just fine. But the reality is not always ideal, if the ipad version needs to be redesigned, the position of the button is changed (refer to the 2nd above), this time need to change all the code? This Nima workload is too great.

Usually the iphone version and ipad version no matter how the UI changes, the business logic is basically the same, then if our code level is clear, is not the controller and model layer can be the perfect reuse, for different versions of a set of view, This is not more convenient, feel a bit.

second, how to solve these problems

The first part said so much finally humorous, how to use the MVC model better to lean to VC, improve reusability and maintainability it? I drew the following diagram:

Explain the above picture, a complete module is divided into three relatively independent parts, respectively, Model,view,controller, corresponding to our app in order to inherit from the NSObject data center, View that hosts UI impressions and event responses, and the most common uiviewcontroller we use.

VC holds the view and model part, view through the proxy or target-action way the user's actions to VC,VC responsible for different user behavior to make different responses. If you need to load or refresh the data, call the model exposed interface directly, and if the data can be synchronized, refresh the view directly using the data obtained. If the data needs to be obtained through other asynchronous means, such as network requests, the VC will listen to the data update (success or failure) notification by the model, and when the notification is received, the view is refreshed according to the success or failure. It can be seen that the whole process of view and model is not directly interactive, all operations are through the VC coordination.

The benefits of being in the MVC hierarchy:

1, VC code Volume dips, easy to maintain

You can see that after the split VC only the response of the event is left, all the display related things are extracted separately, all the network requests and data cache are extracted out. The code in the VC will be greatly reduced, in our project The result is: Split the previous VC code line number of 2600 lines, after splitting the VC line of code only less than 600 lines.

2, the reuse of the improvement

After splitting, if the app needs to make a big change to the UI display, then your changes will basically stay in the View module, you can choose to change the existing base, or you can choose to write one. The model and VC modules do not need to be modified at all, as long as the business is unchanged. This change is small in scope and friendly to both development and testing.

After splitting if the app needs to support the ipad version, then all you need to do is rewrite a view and put it in, the model and VC module also basically do not make any changes, think is not a little excited about it.

Iii. Summary

The use of MVC mode can be achieved to help VC slimming, can go to improve reusability and maintainability of the effect, but also let the original a whole business code, scattered to different places. In actual use we need concrete analysis of specific problems, if the things in a VC itself is very simple, then it can be put together, because even if all put together is hundreds of lines of code. For example, the common copyright interface in the app, which is loaded with an HTML itself, does not have to be so complicated; If a VC is already very complex, the code is often thousands of lines, then you need to split, to achieve better reuse and convenient maintenance purposes.

Wrote a few years of code, saw everything to a source file inside plug, also saw a very simple thing is the design pattern of the fragmented, not to use design patterns and design patterns. It is very important to grasp the good degree, can solve the problem with bullets do not move the cannon.

Code refactoring should be a long-lasting process in which the existing unreasonable places are refactored in the process of development, rather than waiting for a lot of problems to think about refactoring. A dikes Yixue.

Original link: smileevday

SOURCE Link: http://www.cnblogs.com/smileEvday/p/iOS_MVC.html

iOS Dev > Learning-use MVC mode to help Viewcontroller slim