Summary of iOS MVC-based project Reconstruction

Summary of iOS MVC-based project Reconstruction
MVC in iOS and MVPCocoa

According to the description on the official website, MVC in Cocoa is like this:

• Model Objects Encapsulate Data and Basic Behaviors

• View Objects Present Information to the User

• Controller Objects Tie the Model to the View

  Difference between C and P

  Through the search engine, we found that there are actually two types of MVP:

  1. Passive View

  2. Supervising Controller

     The MVP article on the internet is actually about Passive View. Here we put a Passive View:

     Does it look like MVC at first glance? I am still confused until I see this answer in stackoverflow:

     MVP: the view is in charge. the view, in most cases, creates its presenter. the presenter will interact with the model and manipulate the view through an interface. the view will sometimes interact with the presenter, usually through some interfaces. this comes down to implementation; do you want the view to call methods on the presenter or do you want the view to have events the presenter listens t O? It boils down to this: The view knows about the presenter. The view delegates to the presenter.

     MVC: the controller is in charge. the controller is created or accessed based on some event/request. the controller then creates the appropriate view and interacts with the model to further configure the view. it boils down to: the controller creates and manages the view; the view is slave to the controller. the view does not know about the controller.

     In short, MVPs are View-driven. The View layer holds a reference for the Presenter. The interaction event on the View first calls the interface provided by the Presenter, and then the Presenter calls the method provided by the Model to obtain data, finally, the Presenter transmits the obtained data to the View for display.

     MVC is driven by the Controller. The Controller holds the View and responds to the Interaction Events on the View. It calls different Model methods based on the interaction to obtain the feedback data and then transmits the data to the View for display.

     In my understanding, MVP is a user perspective: What you see is View. MVC is a programmer perspective: I control everyone.

     The difference between MVC and MVP lies in whether the UIViewController belongs to the C (P) layer or the V layer? The following two points are analyzed separately.

     Viewpoint 1: UIViewController attribution ---> View

     If you regard UIViewController as the V layer, that is, the Passive View in the MVP above, UIViewController is only responsible for the View layout logic and does not involve any interaction with the Model layer !!

     No interaction with the Model layer is involved !!

     No interaction with the Model layer is involved !!

     All business logic interactions are completed by calling the Presenter and Model held by UIViewController.

     Opinion 2: UIViewController attribution ---> Controller

     If we regard UIViewController as the C layer, from the perspective of MVC design philosophy, the C layer will not be responsible for the layout and presentation logic of the specific View. However, due to the special design of UIViewController in iOS, as a result, many developers directly include a lot of layout-related code in UIViewController. What's more terrible is that not only the initialization of View, including network requests and specific service processing are also included in UIViewController, which may be the reason why MVC is called MassiveViewController.

     Differences between Model, DataInfo, and Model and DataInfo

     In the MVC Architecture, Model is more inclined to be a Layer than an Object (bean in Java or Android ).

     Therefore, the DataInfo here is defined as a DTO (Data Transfer Objec). More simply, it is a Data structure, this is basically the same as the student structure we wrote when learning C language at school.

     In my understanding, Model is used to process business Logic. It can be seen as a combination of BLL (Bussiness Logic Layer) and DAL (Data Access Layer) in the traditional three-tier development architecture, responsible for all specific services. for example, for an App that includes security authentication, you may need an AuthModel to perform local persistence of all authentication logic and authentication information. in this way, the Controller only needs to call the interface provided by AuthModel to complete the corresponding security authentication function, with clear responsibilities.

     The DTO generated by some methods in the Model is used to update the View. for example, UserModel queries user information, converts the user information returned by the server into a local UserInfo, and passes this UserInfo to the View for display.

     Therefore, the industry's controversy over the fat and thin Model is more about whether DataInfo needs to provide business-related extended functions.

     Business scenario example

     For example, in a business scenario, a user information View needs to show the user gender. Generally, the server only contains one sex field in the returned user information (0 indicates female, and 1 indicates male ), when necessary, you may need to use the if statement to determine and output different gender texts or images.

     In terms of personal habits, many developers will convert the user information returned by the server into a local UserInfo DTO, and then pass the DTO to the View to be displayed, then, make an output judgment in the View.

     Of course, developers may use some popular dictionary-to-model frameworks (such as YYModel and MJextension ), you can also use the configuration interfaces provided by these frameworks to convert the output logic during conversion, or directly convert the output in the getter method of the UerInfo sex attribute.

     In any case, as long as similar conversions are made at the DataInfo level, the business logic has penetrated the definition of DTO.

     A solution

     However, this scenario is almost inevitable. How can this problem be solved? The misunderstood MVC and the god-driven MVVM proposed a solution to learn from MVVM. The specific method is to abstract the process of passing ViewController to View data into a ViewModel. after this abstraction, the View only accepts ViewModel, while the Controller only needs to pass such a line of code as ViewModel. In addition, the ViewModel construction process can be moved to another class.

     In my opinion, in this way, the ViewModel layer only extracts the extended DataInfo from the previous section. In this way, the View layer is completely isolated from the business logic.

     Problems to be Solved In this MVC-based project reconstruction step

     Back to the problem of Project reconstruction, I think the first question to be clear about Project reconstruction is:

     1. How are project levels divided?

     2. What are the major business scenarios?

     3. Will UIViewController be classified as View or Controller?

     4. Who is responsible for network requests, Model or Controller?

     5. After obtaining data from the Model, how does the Controller pass the data to the View for display? Are passed by View level? Do I need to use ViewModel?

     6. How to control the Model lifecycle? (Global Model and private Model Division)

     7. How do I transmit user interaction operations when the View hierarchy is getting deeper and deeper? (No doubt NSNotification)

        UIViewController Division

        In This refactoring, we still classify UIViewController as layer C. However, to completely separate UIViewController from UIView, we directly use XXXController, we have designed a corresponding XXXContainerView object for each XXXController. All view la s will be completed in this XXXContainerView.

        Project directory structure

        The restructured project directory structure is as follows:

        Level 1 directory	Subdirectory	Directory description
        Macro		Store some macro definitions required during development
        Category		Stores non-involved services and is used to assist development in classification
        Tools	Different Service Tools	Stores processing classes involving lightweight services, such as outputting different strings according to different business formatting
        Views	Different service module page names	Store V under different service module pages
        Controllers	Different service module page names	Store C under different service module pages
        ViewModels	Different data module names	The Data Translation Layer translates DataInfo data into data that can be directly displayed by View, But This refactoring is not mandatory due to time factors.
        Model	PublicModel	Public global Model, such as user information UserModel
        	MoudleModel	A private Model used by a module is only responsible for private business.
        Services	Different services	Provides underlying services, such as HttpService and SecurityService.

        Business scenario Division

        Due to the previous development schedule, no specific functional splitting was made. Before this reconstruction, StartUML was used to draw the UML diagram in main scenarios, including class diagram, sequence diagram, and flowchart.

        We strongly recommend that you complete this step before the new project is officially coded, and the front-end Technical Director will host the UML review. all the property and public methods of the involved business Model, all the attributes of the DataInfo class, and even all controllers will be generated during the UML rendering process. of course, it may take a long time to draw a UML diagram in all scenarios. Generally, you only need to draw the main interaction scenario.

        Network request

        Basically all network requests on the mobile phone end are linked to the business, which is obviously more suitable in the Model. as for the callback after the request is completed, it seems like my habits. delegate or block is feasible.

        Follow-up

        Because of the time, I did not write the specific sample code. Later, I will write the reference code for each MV (X) mode I understand for a sample scenario. I look forward to discussing it with my peers after writing it.

        MVVM Extension

        Put an MVVM:

        Does it look like MVP? Only two-way binding between View and ViewModel is added. It is emphasized that RAC does not necessarily log on to MVVM, and MVVM does not have to use RAC.