In the tenth year, what choice did Gudong make?

[51CTO.com original article] The launch of the first generation of iPhone in 2007 ushered in a new era of smartphones. Mobile development has spanned a decade, and there have been many changes in the past ten years. With the rapid development of mobile Internet, people's lifestyles are also changing day by day. People living in a monotonous life are also beginning to pay attention to a healthy lifestyle. Codoon has taken a fancy to this market and is committed to encouraging people to form good exercise habits and lifestyles through gamification, socialization and fragmentation, so as to achieve physical health.

At the 2017 WOTA Global Architecture and Operation Technology Summit hosted by 51CTO, Gudong Technical Director Tang Pinglin shared a speech entitled "The Tenth Year of Choice".

[[189728]]

As China's largest sports social service platform, Gudong's APP needs to be bound to a lot of mobile phone hardware, basically using all the chips and sensors in the phone, so it is more conservative in its choice of architecture compared to other APPs. In order to take care of the binding with mobile phone hardware, Gudong hardly uses dynamic technologies such as React Native. In order to ensure the stability of the system, Gudong prefers to choose native implementation. Conservative implementation in architecture will be relatively complex, and Gudong faces such a problem.

Gudong initially chose the MVC framework. Classic MVC is different from Apple's MVC. In Apple's MVC, the Model (data manager), View (data presenter), and Controller (data processor) are interconnected, so all operations on the Model must go through the Controller. As a result, the Controller will become larger and larger. In classic MVC, the View and Controller can be of the same nature, but Apple's cannot. Cocoa MVC = MVC + Data Service lacks the connection between View and Model. This is why the Controller in Apple's architecture becomes larger and larger, which will eventually lead to very big problems.

The fat model contains some weak business logic. The purpose of the fat model is that after the controller gets the data from the fat model, it can directly apply the data to the view without any additional operations or with very few operations. The thin model is only responsible for the expression of business data, and all businesses, whether strong or weak, are handled by the controller. The purpose of the thin model is to write fine-grained models as much as possible, with various helper classes or methods to abstract weak businesses, and strong businesses are still handed over to the controller. Once the fat model is selected, after the controller gets the data, it can display the data in the controller without making too many choices. Sometimes, for the sake of choice, Gudong will also use the thin model, but dare not write any business logic into the model, just use the model as a data storage purpose. At this time, the business processing still requires the controller. There is actually no difference between these two settings, but the fat model is more suitable for Gudong.

Whether it is the server, front-end or client, the collection mode is the most commonly used by developers, and the data is relatively complete. However, the MVC architecture leads to high coupling and complex code. In order to solve this problem, the next architecture is introduced. In MVC, how to divide the code to be clearer and more reasonable? Teacher Tang Pinglin believes that "the Model should be strictly made into a fat Model" so that the View Controller can obtain data without complicated programs.

But sometimes when designing the framework, the design is not strict, then we need to introduce another mode, MVVM. It only does one thing, that is, it splits the View Controller into the View Model, and puts all the control codes of the Controller to the Model into the View Model. In this way, the business logic will be very clear and the framework will be more obvious. The View Controller is only for display, and the View Model is for business processing. The Model can be designed as a fat Model or a thin Model. If it is designed as a fat Model, the simplest logic can be put in the Model for processing. If it is designed as a thin Model, all the data can be put in the View Model for processing.

The View Controller of MVVM is not like the View Controller in MVC. The View Controller + View of MVVM are all integrated into one layer, and this layer is all for display logic. It is worth noting that when doing the view layer and the View Model layer, a Data binding technology must be used between the two. In order to implement this Data binding, third-party libraries cannot be used to supplement it. The role of the View Model is to handle business logic. In addition to being held by the View layer, it also holds the Model. In short, the View Model is a top-to-bottom persistent relationship. In the MVC architecture, it often causes mutual holding among the three. For the development process, a mutual holding relationship may be created between the Model, Controller, and View.

From MVC to MVVM, when the program becomes more and more complex, developers must strictly define what each working module should do. Only then can the code be clearer and more reliable.

Teacher Tang Pinglin advises everyone here, "I hope that everyone will still tend to use the simpler MVC architecture in the project team in the future work, but when the project starts, we must strictly distinguish the relationship between the three, what code can be written and what code cannot be written among the three, and what code should be placed in what. For example, I must use a fat model in my model, I must not operate the animation of the View layer in the Controller, and I must not write logic related to users and business codes in the View. If we do these three points well, we can still do architecture in MVC."

[51CTO original article, please indicate the original author and source as 51CTO.com when reprinting on partner sites]