First, the choice of framework mode
1. The MVC pattern
MVC is the full name of Model View Controller, is Model (Model)- View (View)- Controller (Controller) abbreviation, a software design Model, with a business logic, data, interface display separation method organization code, business logic gathered into a component, There is no need to rewrite the business logic while improving and personalizing the interface and user interactions. MVC was uniquely developed to map traditional input, processing, and output functions into a logical graphical user interface structure.
1.1 MVC programming mode
MVC is a pattern that uses Model View Controller (MVC) to design applications
-
View: Responsible for data display, listening to user touch and other work
-
Controller: Is responsible for service logic, event response, and data processing
-
Model (Controller) : Responsible for encapsulating data, storing and processing data operations
1.2 MVC communication features
-
Models and views can never communicate with each other, only through the Controller.
-
The Controller communicates directly with the Model (reading and writing the Model), and the Model communicates indirectly with the Controller through Notification and KVO mechanisms.
-
The Controller communicates with the View through Target/Action, delegate, and datasource modes.
With these three modes, the View can communicate to the Controller. The Action/Target mode allows the Controller to listen for events that the View triggers. The View performs Data acquisition and some communication operations through Data source and delegate.
1.3 Advantages and Disadvantages of MVC
1. Ease of use: Minimal amount of code compared to the other modes and easy to maintain.
2. Testability: Because of poor dispersion, only the Model can be tested.
3. Balance: Thick ViewController, nowhere to put network logic and data logic.
2. MVCS mode
Apple itself is using this architecture idea, from the name can also be seen, is also based on MVC derived from a set of architecture. Conceptually, the split is the Model part, which is a Store. This Store is dedicated to data access.
For practical purposes, it takes apart the Controller. Since the Controller does the data storage thing, it’s going to be very large, so take the part of the Controller that’s responsible for storing and accessing data and give it to another object, which is the Store. After this adjustment, the entire structure becomes a true MVCS.
-
View: user interface
-
Controller: service logic and processing
-
Model: data storage
-
Store: Data processing logic
MVCS is an architectural idea based on the thin Model. It abstracts some of the code about data storage from many things that the Model is supposed to do into a Store, which reduces the pressure on the Controller to some extent.
3. The MVP pattern
MVP (Model-View-Presenter) is evolved from the classic pattern MVC. The basic ideas of the two are similar: Controller/Presenter is responsible for logic processing, Model provides data, and View is responsible for display.
3.1 Pros and cons of MVP mode
-
The model is completely separate from the view, and we can modify the view without affecting the model.
-
The model can be used more efficiently because all interactions take place inside the Presenter.
-
A Presenter can be used for multiple views without changing the Presenter logic.
-
If we put the logic in a Presenter, then we can test the logic outside of the user interface.
-
Because the rendering of the view is in a Presenter, the view interacts with the Presenter too often, and if the view needs to change, the Presenter needs to change.
3.2 Differences between MVP and MVC:
-
In MVP, views don’t use models directly. They communicate with each other through a Presenter (the Controller in MVC), and all interaction takes place inside the Presenter. In MVC, the View reads data directly from the Model instead of through the Controller.
-
In MVP, view refers to Presenter, Presenter does not refer to view. The Presenter refers to the Model, but the Model does not refer to the Presenter.
-
In MVC, the View has direct access to the Model. The View contains the Model information and, inevitably, some business logic. In the MVC Model, the Model doesn’t depend on the View, but the View depends on the Model. Because some of the business logic is implemented in the View, the View is less reusable.
-
In MVC, it is not recommended to rely on the Model in the View. Instead, as much as possible, the business logic is handled in the Controller and the View only interacts with the Controller.
4. The MVVM pattern
MVVM is short for Model-view-ViewModel. It’s essentially an improved version of MVC. MVVM abstracts the state and behavior of its views, allowing us to separate the View UI from the business logic. Of course, the ViewModel already does this for us, it pulls out the data from the Model and it also helps with the business logic involved in the View because you need to present the content.
The origin of MVVM (Model-View-ViewModel) framework is a new architecture framework developed by the combination of MVP (Model-View-Presenter) mode and WPF. It builds on the original MVP framework and incorporates new FEATURES of WPF in response to changing and increasingly complex customer needs.
4.1 Components of the MVVM mode
-
Model: A model is either a domain model (object-oriented) that represents the content of the real state, or a data access layer (data-centric) that represents the content.
-
Views: As in MVC and MVP mode, a view is the structure, layout, and appearance (UI) that the user sees on the screen.
-
Viewmodel: A viewmodel is an abstraction of a view that exposes common properties and commands. In the viewmodel, binders communicate between views and data binders.
Reference features: View references viewModel, viewModel does not reference View (i.e., do not introduce #import UIkit. h in viewModel, any reference to view itself should not be placed in viewModel); ViewModel references Model, model does not reference viewModel.
3.2 MVVM advantages
-
Low coupling: Views can be changed and modified independently of the Model, a ViewModel can be bound to different views, the Model can be unchanged when the View changes, and the View can be unchanged when the Model changes.
-
Reusability: You can put some view logic in a ViewModel and have many views reuse that view logic.
-
Independent development: Developers can focus on business logic and data development (ViewModel), and designers can focus on page design.
-
Testable: Interface elements are more difficult to test, but tests can now be written against the ViewModel.
3.2 Differences between MVVM and MVP:
The MVVM mode renamed Presener to ViewModel, which is basically the same as the MVP mode. The only difference is that MVVM can be combined with RAC (MVVM+RAC) to implement bidirectional binding between View and ViewModel, so that developers don’t have to deal with receiving events and View updates.
Common base library and cocoaPod application
1. Directory distribution of common base libraries
【Service】 Service layer, which stores common business logic and common services, such as common interfaces, basic component configurations, user information, shared data, page routing configurations, etc.
[BaseKit] The base layer, which holds the common base libraries applied to each business module.
CommonLib: Common function components, implementation and application of specific functions, such as APM, data reporting, page routing, OCR, etc.
Views: Generic view components, such as BannerView, AlertView, pageControl, loadingView, etc.
Kernal: basic service component that provides basic service capabilities, such as Network, Log, dataBase, and webImage.
Basic: Basic class, and divided into MVC three subdirectories, encapsulate the Basic class.
Marco: A generic declaration with macro define and constant declaration -extern.
Utils: collection of tool classes, such as Tools, Authoritys, Encrypt, NetworkAccessible, etc.
Categorys: a common category extension that can be classified into different categories according to different attributes, such as View, Datas, Image, etc.
Note: Top-down dependencies
2. CocoaPod application
IOS developers should be familiar with cocoaPod, the main use of third-party libraries and private component libraries to facilitate iteration management.
2.1 GitHub third-party libraries
– use article of CocoaPods explanation: blog.csdn.net/meegomeego/…
2.2 GitLab Private library
CocoaPod – spec private library configuration: blog.csdn.net/z119901214/…
Business components & Component communication
1. Service components
Business component mainly refers to a large business module that is separated into a single component, such as e-commerce module, chat module, blog, etc. There is no coupling code between business components, and the communication between them is realized by the component communication middle layer.
1.1 Stratification of group price
A is the main project, and B and C are the two service module directories. In the main service directory, create different directories based on different service components. Service modules are independent, and components do not directly call apis.
Xcworkspace layer: In the XCWorkspace mode, different business modules create their own projects. After the business project runs successfully, the framework is introduced into the main project.
Pod components are layered: Business components are introduced with poD-specs, and each business module is a separate project. For details, see Github’s componentization project ios-Components-Pro
1.2 Features of the layered component mode
-
Directory layering: Directory layering is relatively simple, with no real code segmentation, so directories and their classes can be referenced, which is highly dependent on the discipline of team development.
-
Xcworkspace layer: The XCWorkspace layer implements the separation of code from different business components and is introduced as a framework. The introduction of dynamic compilation will affect the efficiency of compilation and packaging. Introducing update iterations packaged as a static framework is costly and not good for cocoaPod.
-
Pod component layer: the realization of different business component code segmentation, but also to solve the XCWorkspace layer affect compilation efficiency and is not beneficial to cocoaPod use, business components and basic components unified use cocoaPod management.