[Love Swift] day7:[turn] my iOS engineering structure

Transferred from: http://www.cocoachina.com/ios/20140930/9810.html

A good architecture is not designed, but evolved!

Write in front

Starting from the end of 2011 to learn iOS development, it has been almost 3 years now, although not always in the middle of iOS development (always between Android and iOS switch), but never left, and I now work the same, the iOS and Android to walk back and forth, Just like my blog's slogan, "in Android&ios". In fact, for me, two platforms are not absolutely good or bad, I like, I love. Some people will say that the same product on different platforms do not feel bored two times? I will give a definite answer to this question, no! Because if you really like what you do, how many times you don't get bored, each time the re-reel is a process of improvement, and many innovations are produced in repetitive work. At the technical level, the same set of ideas with different technologies to achieve, in itself is a strengthening of the different platform technology consolidation and understanding of the process, technology is to carry out and performance of the business, in the process of business to enhance understanding of business, to achieve business innovation, this is perhaps the difference between the heap code and writing program! ^_^

my IOS engineering structure

Next, I'll briefly describe the engineering structure that I used when I made my iOS project. The first thing to say is that this is just my engineering structure, is not a norm, perhaps it has a lot of problems and not norms of the place, I just share it out, to provide a reference, but also hope to receive some feedback from everyone to help me improve!

Project structure

I do an iOS project is a common engineering structure, the overall mode or according to the structure of MVC, just in each layer to do some subdivision processing, the following is a brief introduction.

There is no very strict subcontracting mechanism like Java in iOS engineering, but we can also implement logical subcontracting in the project by group in the iOS project, which is more advantageous for us to organize and manage the code, make the engineering structure clearer and easier to understand. In my engineering structure, there are mainly the following group:

Application: This group puts the appdelegate and some system constants and system configuration files;

Base: Some basic parent classes, including parent Viewcontroller and some common top-level custom parent classes, the classes of other modules generally inherit from some of the classes here;

controller: The system control layer, the placement of Viewcontroller, are inherited from the group base of Baseviewcontroller or Basetableviewcontroller;

View : The views layer in the system, because I prefer to implement the interface through the code, so here is the view that inherits from the UIView, I separated the view from the Viewcontroller and put it all here, This will keep the viewcontroller streamlined;

Model: an entity in a system that describes some of the roles and services in a system, and includes the processing logic corresponding to those roles and services;

Handler: The System business Logic layer, is responsible for processing the system complex business logic, the upper level caller is the Viewcontroller;

Storage: simple data storage, mainly a number of key values for storage and system external file access, including the Nsuserdefault and plist access to the package;

Network processing layer (rthttpclient), which encapsulates the afnetworking-based network processing layer, implements the callback of processing result by block, the upper caller is the handler layer;

Database : data layer, encapsulating SQLite database access and Management (Rtdatabasehelper) based on Fmdb, providing external call interface based on the model Layer object, encapsulating the stored procedure of data.

Utils: System Tool Class (Apputils), mainly put some system common tools class;

Categories: categories, extensions to existing system classes and custom classes;

Resource: resource library, including pictures, plist files, etc.;

The above is to my engineering structure of each group's introduction, through the following login module system class diagram, can be more intuitive to see the full picture of this engineering structure.

The overall view is divided into three chunks, the yellow area of the model and the Business Logic layer (M), the blue area of the views layer (V), the red area of the View Controller layer (C), where the yellow region implements the business logic and data processing encapsulation, corresponding to their upper Viewcontroller, A very simple interface call can be implemented to extract the business complexity from the viewcontroller and to ensure the readability and maintainability of the Viewcontroller through a modular approach.

Keep Viewcontroller Simple

Often everyone complains that iOS Viewcontroller is getting bloated when it comes to writing, because with the complexity of the business and the increase in functionality, all the logic is contained in the Viewcontroller, Also includes some agent methods such as Uitableviewdatasource, make Viewcontroller bloated, maintainability is very low, coupling is also very high, in order to make viewcontroller easier, easy maintenance and follow-up development, To Viewcontroller thin body is particularly necessary, my approach mainly has three aspects.

1. The view view is separated from the Viewcontroller

If you use storyboard or xib This is of course, I prefer handwritten code, so not embedded in viewcontroller too much view layer code is to ensure Viewcontroller simple method, then, You can encapsulate the code for the view section separately into a subclass that inherits from UIView, and then implement the view and Viewcontroller communication through a custom delegate.

2. Separation of business logic and Viewcontroller

Putting network request processing and complex business logic and data access to the handler layer alone exposes only simple calling interfaces and callbacks implemented through blocks or delegate, which not only enables our engineering to be modular, It can also greatly reduce the complexity of viewcontroller, and there will be no lengthy Viewcontroller code that includes both network processing and data processing. Handler The result is processed by a block or delegate to the Viewcontroller,viewcontroller and then associated with the View view layer, which really plays the role of MVC, and the overall principle is that Let Viewcontroller only relate and be responsible for dealing with things related to it.

In BaseHandler.h, you can define some simple business processing rules:

#import <Foundation/Foundation.h>  /**  *  handler block */typedef void called after processing is completed  (^completeblock )();  /**  *  Handler The block */  typedef void (^successblock) (id obj) called when processing succeeds;  /**  *  The block *  /typedef void (^failedblock) (ID obj) that was called when processing failed handler;  @interface basehandler:nsobject  /**  *  GET request URL  *  *  @param path  *  @return Assembled URL *  /+ (NSString *) Requesturlwithpath: (NSString *) path;  

In Loginhandler, it is possible to define a calling interface for Loginviewcontroller exposure, encapsulating the responsible network processing and business processing logic in Loginhandler, and for Loginviewcontroller, Just call this method and pass in the corresponding Userentity entity object and handle the callback block on the success and failure states.

#import "BaseHandler.h" #import "UserEntity.h"  @interface loginhandler:basehandler  /**  *  User Login business logic processing  *  *  @param user  *  @param success  *  @param failed */    -(void) Executelogintaskwithuser: (userentity *) User success: (Successblock) Success failed: (Failedblock) failed;  

3, DataSource or delegate and Viewcontroller separation

UITableView, often used in iOS development, contains a series of proxy methods that are often one of the culprits that make viewcontroller grow more complicated, so separating these datasource or delegate is one of the most effective ways. , for example, by customizing the DataSource Class (Implementing the Uitableviewdatasource Protocol) to centralize UITableView-related data source processing proxy methods into a specific class, Viewcontroller only need to set this custom data source class to UITableView, and then the rest can be handed to the custom data source class to handle.

I refer to the introduction of lighter View controllers to improve a basetableviewprotocol, basically some of the commonly used scenarios are available, but this has to be constantly optimized to adapt to more scenes, specific code I put on GitHub, Interested students can go to see, the use of the method can refer to the above link in the introduction, basically similar, my improvement is mainly to support the application of multiple sections.

BaseTableViewProtocol.h

basetableviewprotocol.m

Written in the last

The above is the development of my iOS project in some of the summary and engineering practices, which certainly still have a lot of problems, I am also constantly seeking ways to improve, but also welcome the experts to give me advice and suggestions. A simple example of this engineering structure I put on my github, interested students can go to see Rtlibrary-ios.

[Love Swift] day7:[turn] my iOS engineering structure