First, the common phenomena and shortcomings in development.
One of the most common design patterns in iOS is MVC, but in the actual development process, due to one reason or another, we have turned the simple ViewController into a large collection of models, controllers and views, which will inevitably lead to a geometric increase in the code capacity of VC. There are several problems with this code:
1, which is not conducive to subsequent maintenance.
Code usually survives in the company much longer than you do in the company. Do you say "shit" in your head after reading the code after taking over the existing project? I don't think anyone wants the person who takes over your code to read your code one day and say the same thing in his head. As an aspiring programmer, or in order not to be scolded by future colleagues, we must be responsible for our own code and avoid becoming a source file with thousands of lines. You don't even want to read what you wrote, let alone those who took over later.
If the project is urgent, there is no time to split and reconstruct the code reasonably at that time, and the pit dug later must take time to make up. You may say that the company has been busy and has no time to reorganize for you. I can only say that either you can't arrange your own time, or this company only treats you as a code porter. In the long run, either change yourself or fire your boss.
2. It is not conducive to supporting UI changes.
Imagine that if the UI style of your App needs to be changed one day, a large number of views need to be changed. What does it feel like to delete changes in a VC with thousands of lines? It may be because something in the model or controller was accidentally changed when the UI was changed, resulting in the program not running normally. Moreover, the range of change can not be controlled in a small range, and the workload of testing regression is also very large.
3, not conducive to reuse
If your App only supports the iPhone version at first, everything will be so natural and the program will run well. Suddenly one day, the boss tells you that the company's business is developing well, and in order to expand the market, it is necessary to quit the iPad version. At this time, if it is only an enlarged version of the iPhone version, then what you need to do may be to add some adaptation of view. However, the reality is not always ideal. If the iPad version needs to be redesigned and the key positions have changed (refer to the second point above), do you need to change all the codes at this time? This is too much fucking work.
Usually, no matter how the UI changes, the business logic of iPhone version and iPad version is basically the same. So if our code level is clear at the beginning, can the controller and model layer be perfectly reused? Just change a set of views for different versions. Is this much more convenient? Feel for yourself.
Second, how to solve these problems?
The first part has said so much and finally got to the point. How to use MVC mode to better slim down VC and improve reusability and maintainability? I drew the following picture:
Explain the above picture. A complete module is divided into three relatively independent parts, namely, model, view and controller, which correspond to the data center inherited from NSObject in our App. View carries UI display and event response, and our most commonly used UIViewController.
Among them, VC holds views and models. View passes the user's operation to VC through proxy or Target-Action, and VC is responsible for making different responses according to different user behaviors. If you need to load or refresh data, you can directly call the interface exposed by Model. If the data can be obtained synchronously, you can refresh the view directly with the obtained data. If you need to obtain data through other asynchronous methods such as network request, VC will listen to the data update (success or failure) notification sent by Model, and refresh the view according to success or failure when receiving the notification. It can be seen that there is no direct interaction between the view and the model in the whole process, and all operations are coordinated through VC.
Benefits of experiencing MVC layering:
1, the amount of VC code drops sharply, which is easy to maintain.
It can be seen that only the event response operation is left in the split VC, and all display related things are extracted separately, and all network requests and data caches are extracted. The code in VC will be greatly reduced. The actual result of our project is that the number of code lines in VC was 2600 before, and the number of code lines in split VC was less than 600.
2, the reusability is improved.
After the split, if the App needs to make major changes to the UI display, then your changes will basically stay in the view module. You can choose to modify the existing one or write one from scratch. As long as the business remains unchanged, the model and VC module do not need to be modified at all. This change is small and friendly to development and testing.
After the split, 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 basically do not need to be modified. Think about whether you are still a little excited.
Third, summary.
Using MVC pattern can help VC slim down, improve reusability and maintainability, and at the same time make the original whole business code scattered in different places. In practical use, specific problems need to be analyzed. If things in a VC are simple, they can be put together, because even if they are all put together, there are only a few hundred lines of code. For example, the common copyright interface of the App itself just loads an html, so there is no need to make it so complicated. If a VC is already very complicated and has thousands of lines of code, it needs to be split to achieve better reuse and convenient maintenance.
I have been writing code for several years. I've seen everything stuffed into a source file, and I've seen a simple thing torn to pieces by design patterns. Don't use them just to use design patterns. It is very important to grasp the degree, and don't use cannons to solve the problems that bullets can solve.
Code refactoring should be a lasting process. In the process of development, the existing unreasonable places are reconstructed from time to time, instead of waiting for many problems to think of reconstruction. A journey of a thousand miles begins with a single step, and the embankment of a thousand miles collapses in the ant nest.