[愛上Swift] day7:[轉]我的iOS工程結構

來源:互聯網
上載者:User

標籤:android   blog   http   io   os   使用   ar   java   strong   

轉自:http://www.cocoachina.com/ios/20140930/9810.html

好的架構不是設計出來的,而是進化而來的!

寫在前面

從2011年底開始學習iOS開發,到現在也已經快3年了,雖然中途沒有一直進行iOS的開發(總是在Android和iOS間切換),但始終沒有離開,而我現在的工作也一樣,在iOS和Android間來回遊走,正如我部落格的slogan一樣,“In Android&iOS”。其實對我來說,兩個平台沒有絕對的好壞,我都喜歡、我都熱愛。有人會說,同樣的產品在不同平台做兩次不會覺得厭煩嗎?這個問題我會給出肯定的回答,不會!因為如果你真的喜歡你所做的產品,做多少次都不會覺得煩,每一次的複盤都是一次改進的過程,很多創新都是在重複的工作中產生的。在技術層面,同一套思想用不同的技術來實現,本身就是一個加強對不同平台技術鞏固和理解的過程,技術本來就是來承載和表現業務的,在實現業務的過程中加強對業務的理解、實現對業務的創新,這或許也就是堆代碼和寫程式的區別吧!^_^

 我的iOS工程結構

接下來,我就簡單介紹下我做iOS項目時使用的工程結構。首先要說的是,這隻是我的工程結構,並不是規範,或許它存在很多問題和不規範的地方,我只是把它分享出來,給大家提供一個參考,也希望收到大家的一些反饋來協助我改進!

項目結構

是我做iOS項目的一個常用工程結構,整體模式還是按照MVC的結構,只是在每一層做了一些細分處理,下面就簡單介紹下。

iOS工程中沒有像Java那樣非常嚴格的分包機制,不過在iOS工程中我們也可以通過Group的方式在工程中實現邏輯分包,這樣更有利於我們組織和管理代碼,使工程結構更清晰和易於理解。在我的工程結構中,主要有如下group:

Application:這個group中放的是AppDelegate和一些系統常量及系統設定檔;

Base:一些基本父類,包括父ViewController和一些公用頂層自訂父類,其他模組的類一般都繼承自這裡的一些類;

Controller:系統控制層,放置ViewController,均繼承於Group Base中的BaseViewController或BaseTableViewController;

View:系統中視圖層,由於我比較喜歡通過代碼實現介面,所以這裡放的都是繼承於UIView的視圖,我將視圖從ViewController中分離出來全部放在這裡,這樣能保持ViewController的精簡;

Model:系統中的實體,通過類來描述系統中的一些角色和業務,同時包含對應這些角色和業務的處理邏輯;

Handler:系統商務邏輯層,負責處理系統複雜商務邏輯,上層調用者是ViewController;

Storage:簡單資料存放區,主要是一些索引值對儲存及系統外部檔案的存取,包括對NSUserDefault和plist存取的封裝;

Network:網路處理層(RTHttpClient),封裝了基於AFNetworking的網路處理層,通過block實現處理結果的回調,上層調用者是Handler層;

Database:資料層,封裝基於FMDB的sqlite資料庫存取和管理(RTDatabaseHelper),對外提供基於Model層對象的調用介面,封裝對資料的預存程序。

Utils:系統工具類(AppUtils),主要放置一些系統常用工具類;

Categories:類別,對現有系統類別和自訂類的擴充;

Resource:資產庫,包括圖片,plist檔案等;

以上是對我的工程結構中各個group的介紹,通過以下登入模組的系統類別圖,可以比較直觀的看到這種工程結構的全貌。

整體來看分為三大塊,黃色地區的模型和商務邏輯層(M),藍色地區的視圖層(V),紅色地區的視圖控制器層(C),其中,黃色地區實現了對商務邏輯和資料處理的封裝,對應他們的上層ViewController,可以實現非常簡單的介面調用,將業務複雜性從ViewController中抽離出來,通過模組化的方式,保證ViewController的可讀性和可維護性。

保持ViewController簡單

往往大家都會抱怨iOS中ViewController寫著寫著就會越來越臃腫,那時因為隨著業務的複雜,功能的增多,所有的邏輯都包含在ViewController中,還包括一些諸如UITableViewDatasource的代理方法,使得ViewController臃腫不堪,可維護性極低,耦合性也很高,為了使ViewController能更簡單,便於維護和後續的開發,給ViewController瘦身就顯得尤為必要,我的做法主要有三個方面。

1、View視圖與ViewController分離

如果你用Storyboard或者xib這是當然的,我比較喜歡手寫代碼,所以不在ViewController裡面嵌入過多的View層代碼是保證ViewController簡單的方法之一,那麼,可以將View部分的代碼單獨封裝到一個繼承自UIView的子類當中,然後通過自訂Delegate實現View與ViewController的通訊。

2、商務邏輯與ViewController分離

將網路請求處理和複雜的商務邏輯以及資料的存取工作單獨放到Handler層,對ViewController只暴露簡單的調用介面和通過block或delegate實現的回調,這樣不僅能使我們的工程模組化,也能大大降低ViewController的複雜性,就不會出現既包括網路處理又包括資料處理的冗長的ViewController代碼了。Handler通過block或delegate將處理完的結果回調給ViewController,ViewController再將結果與View視圖層相關聯處理,這樣就真正起到了MVC的作用,整體原則就是,讓ViewController只關係和負責處理與它相關的事。

在BaseHandler.h中可以定義一些簡單的業務處理規則:

#import <Foundation/Foundation.h>  /**  *  Handler處理完成後調用的Block  */ typedef void (^CompleteBlock)();  /**  *  Handler處理成功時調用的Block  */ typedef void (^SuccessBlock)(id obj);  /**  *  Handler處理失敗時調用的Block  */ typedef void (^FailedBlock)(id obj);  @interface BaseHandler : NSObject  /**  *  擷取請求URL  *  *  @param path  *  @return 拼裝好的URL  */ + (NSString *)requestUrlWithPath:(NSString *)path;  @end 

在LoginHandler中就可以定義對LoginViewController暴露的調用介面,在LoginHandler中封裝負責的網路處理和業務處理邏輯,對LoginViewcontroller來說,只需要調用這個方法並傳入對應的UserEntity實體物件和處理成功和失敗狀態下的回調block就可以了。

#import "BaseHandler.h" #import "UserEntity.h"  @interface LoginHandler : BaseHandler  /**  *  使用者登入商務邏輯處理  *  *  @param user  *  @param success  *  @param failed    */ - (void)executeLoginTaskWithUser:(UserEntity *)user success:(SuccessBlock)success failed:(FailedBlock)failed;  @end 

 3、Datasource或Delegate與ViewController分離

在iOS開發中經常用到的UITableView包含了一系列的代理方法,這些方法往往也是使得ViewController變長變複雜的元兇之一,那麼,將這些Datasource或Delegate分離出來也是行之有效方法之一,例如,通過自訂Datasource類(實現UITableViewDatasource協議)來將跟UITableView相關的資料來源處理代理方法都集中到一個特定的類當中,ViewController只需要設定這個自訂資料來源類給UITableView,然後其他的就都可以交給自訂資料來源類去處理了。

我參考了Lighter View Controllers上的介紹改進了一個BaseTableViewProtocol,基本上常用的一些情境是可以使用的,不過這個還得不斷最佳化以適應更多的情境,具體的代碼我放在Github上了,感興趣的同學可以去看看,使用方法可以參考上面連結中的介紹,基本類似,我的改進主要是支援對多section的適用。

BaseTableViewProtocol.h

BaseTableViewProtocol.m

寫在最後

以上是我在開發iOS項目中的一些總結和工程實踐,其中肯定還是存在很多問題的,我也在不斷尋求改進的方法,也歡迎各路高手給我提出意見和建議。關於這個工程結構的一個簡單案例我放在我的Github上了,感興趣的同學可以去看看RTLibrary-ios。

[愛上Swift] day7:[轉]我的iOS工程結構

聯繫我們

該頁面正文內容均來源於網絡整理,並不代表阿里雲官方的觀點,該頁面所提到的產品和服務也與阿里云無關,如果該頁面內容對您造成了困擾,歡迎寫郵件給我們,收到郵件我們將在5個工作日內處理。

如果您發現本社區中有涉嫌抄襲的內容,歡迎發送郵件至: info-contact@alibabacloud.com 進行舉報並提供相關證據,工作人員會在 5 個工作天內聯絡您,一經查實,本站將立刻刪除涉嫌侵權內容。

A Free Trial That Lets You Build Big!

Start building with 50+ products and up to 12 months usage for Elastic Compute Service

  • Sales Support

    1 on 1 presale consultation

  • After-Sales Support

    24/7 Technical Support 6 Free Tickets per Quarter Faster Response

  • Alibaba Cloud offers highly flexible support services tailored to meet your exact needs.