對于 MVVM 我想說:自已的事情自已做,控制器就簡化了!
<a target="_blank" href="http://blog.csdn.net/opengl_es">轉載請保留此句:太陽火神的美麗人生 - 本部落格專注于 靈活開發及移動和物聯裝置研究:iOS、Android、Html5、Arduino、pcDuino,否則,出自本部落格的文章拒絕轉載或再轉載,謝謝合作。</a>
先來幾個彩蛋:
http://numbbbbb.gitbooks.io/-the-swift-programming-language-/
http://swiftist.org/topics/165#18
http://swiftist.org/topics/148
http://swiftist.org/topics/150
http://swiftist.org/topics/129
http://dev.swiftguide.cn
http://practicalswift.com/2014/06/14/the-swift-standard-library-list-of-built-in-functions/
http://objccn.io/issue-13-1/
http://www.teehanlax.com/blog/model-view-viewmodel-for-ios/
http://www.cnblogs.com/yangfaxian/tag/iOS%20單元測試%20Xcode5/
戳完了沒?!
可别說我這不叫彩蛋,純是扯蛋噢!
扯蛋,就扯蛋吧,本山大叔拎着一串鹌鹑蛋,記憶猶新。
正文開始
有幸閱讀到這麼好的文章,語言描述得如此勁道,汗顔,國文學得太差了,想表達得如此幹淨利落,确力不從心。
關于 MVVM 所要解決的問題,在2010年的時侯,在工作項目中,就已經實踐摸索過,當時總結出一句話:
自已的事情自已做,控制器隻做大老爺!
後來,發現控制器中,有兩件事情:
1、操作視圖們;
2、操作模型們;
第二點,和 MVVM 的作法一樣;
第一點,也無非就是把很多操作封裝到視圖子類中去,由子類自已來完成自已的管理工作,控制器隻需要調用。
不過這樣,有一個麻煩事,就是需要建子類。
就像我們平時說話,想說就說了,也不用打草稿,還得講場合;
但子類化後,就像是在會議上做報告一樣,得打草稿,建子類,把操作内置,然後再調用,到會上拿着稿發言。
當多了的時侯,你就會覺得煩了,但這樣做對于後續疊代分析以及維護,都好處多多。
就像 iOS 中的表視圖,大滾輪這類東西一樣,顯示一行,也要弄那麼多的代理方法,每次都那麼的煩!
凡事都有利有弊;或者說,都有适用的範圍,沒有适用萬事萬物的不變法則,隻有變,才是不變的法則。
以下引用了 MVVM 相關的介紹,标題即為原文連結,猛戳即入!
再補充一句,每一個應用項目,當然多做些分析了抽象之後,你會發現,需要做的事情并不多,但那需要同時完成這個抽象過程在軟體編碼和架構上的同步抽象才行,要不然,這種抽象隻能當作不存在,還以平常視之。
--------------------------
<a target="_blank" href="http://objccn.io/issue-13-1/">MVVM 介紹</a>
朱宏旭 10 Jun 2014
分享文章
我于 2011 年在 500px 找到自己的第一份 iOS 開發工作。雖然我已經在大學裡做了好幾年 iOS 外包開發,但這才是我的一個真正的 iOS 開發工作。我被作為唯一的 iOS 開發者被招聘去實作擁有漂亮設計的 iPad 應用。在短短七周裡,我們就釋出了 1.0 并持續疊代,添加了更多特性,但從本質上,代碼庫也變得更加複雜了。
有時我感覺就像我不知道在做什麼。雖然我知道自己的設計模式——就像任何好的程式設計人員那樣 —— 但我太接近我在做的産品以至于不能客觀地衡量我的架構決策的有效性。當隊伍中來了另外一位開發者時,我意識到我們陷入困境了。
從沒聽過 MVC ?有人稱之為 Massive View Controller(重量級視圖控制器),這就是我們那時候的感覺。我不打算介紹令人汗顔的細節,但說實在的,如果我不得不再次重來一次,我絕對會做出不同的決策。
我會修改一個關鍵架構,并将其帶入我從那時起就在開發的各種應用,即使用一種叫做 Model-View-ViewModel 的架構替換 Model-View-Controller。
是以,MVVM 到底是什麼?與其專注于說明 MVVM 的來曆,不如讓我們看一個典型的 iOS 是如何建構的,并從那裡了解 MVVM:
我們看到的是一個典型的 MVC 設定。Model 呈現資料,View 呈現使用者界面,而 View Controller 調節它兩者之間的互動。Cool!
稍微考慮一下,雖然 View 和 View Controller 是技術上不同的元件,但它們幾乎總是手牽手在一起,成對的。你什麼時候看到一個 View 能夠與不同 View Controller 配對?或者反過來?是以,為什麼不正規化它們的連接配接呢?
這更準确地描述了你可能已經編寫的 MVC 代碼。但它并沒有做太多事情來解決 iOS 應用中日益增長的重量級視圖控制器的問題。在典型的 MVC 應用裡,許多邏輯被放在 View Controller 裡。它們中的一些确實屬于 View Controller,但更多的是所謂的“表示邏輯(presentation logic)”,以 MVVM 屬術語來說,就是那些将 Model 資料轉換為 View 可以呈現的東西的事情,例如将一個 NSDate 轉換為一個格式化過的 NSString。
我們的圖解裡缺少某些東西,那些使我們可以把所有表示邏輯放進去的東西。我們打算将其稱為 “View Model” —— 它位于 View/Controller 與 Model 之間:
看起好多了!這個圖解準确地描述了什麼是 MVVM:一個 MVC 的增強版,我們正式連接配接了視圖和控制器,并将表示邏輯從 Controller 移出放到一個新的對象裡,即 View Model。MVVM 聽起來很複雜,但它本質上就是一個精心優化的 MVC 架構,而 MVC 你早已熟悉。
現在我們知道了什麼是 MVVM,但為什麼我們會想要去使用它呢?在 iOS 上使用 MVVM 的動機,對我來說,無論如何,就是它能減少 View Controller 的複雜性并使得表示邏輯更易于測試。通過一些例子,我們将看到它如何達到這些目标。
此處有三個重點是我希望你看完本文能帶走的:
MVVM 可以相容你當下使用的 MVC 架構。
MVVM 增加你的應用的可測試性。
MVVM 配合一個綁定機制效果最好。
如我們之前所見,MVVM 基本上就是 MVC 的改進版,是以很容易就能看到它如何被整合到現有使用典型 MVC 架構的應用中。讓我們看一個簡單的 Person Model 以及相應的 View Controller:
@interface Person : NSObject
- (instancetype)initwithSalutation:(NSString *)salutation firstName:(NSString *)firstName lastName:(NSString *)lastName birthdate:(NSDate *)birthdate;
@property (nonatomic, readonly) NSString *salutation;
@property (nonatomic, readonly) NSString *firstName;
@property (nonatomic, readonly) NSString *lastName;
@property (nonatomic, readonly) NSDate *birthdate;
@end
Cool!現在我們假設我們有一個 PersonViewController ,在 viewDidLoad 裡,隻需要基于它的 model 屬性設定一些 Label 即可。
- (void)viewDidLoad {
[super viewDidLoad];
if (self.model.salutation.length > 0) {
self.nameLabel.text = [NSString stringWithFormat:@"%@ %@ %@", self.model.salutation, self.model.firstName, self.model.lastName];
} else {
self.nameLabel.text = [NSString stringWithFormat:@"%@ %@", self.model.firstName, self.model.lastName];
}
NSDateFormatter *dateFormatter = [[NSDateFormatter alloc] init];
[dateFormatter setDateFormat:@"EEEE MMMM d, yyyy"];
self.birthdateLabel.text = [dateFormatter stringFromDate:model.birthdate];
}
這全都直截了當,标準的 MVC。現在來看看我們如何用一個 View Model 來增強它。
@interface PersonViewModel : NSObject
- (instancetype)initWithPerson:(Person *)person;
@property (nonatomic, readonly) Person *person;
@property (nonatomic, readonly) NSString *nameText;
@property (nonatomic, readonly) NSString *birthdateText;
我們的 View Model 的實作大概如下:
@implementation PersonViewModel
- (instancetype)initWithPerson:(Person *)person {
self = [super init];
if (!self) return nil;
_person = person;
if (person.salutation.length > 0) {
_nameText = [NSString stringWithFormat:@"%@ %@ %@", self.person.salutation, self.person.firstName, self.person.lastName];
_nameText = [NSString stringWithFormat:@"%@ %@", self.person.firstName, self.person.lastName];
_birthdateText = [dateFormatter stringFromDate:person.birthdate];
return self;
Cool!我們已經将 viewDidLoad 中的表示邏輯放入我們的 View Model 裡了。此時,我們新的 viewDidLoad 就會非常輕量:
self.nameLabel.text = self.viewModel.nameText;
self.birthdateLabel.text = self.viewModel.birthdateText;
可測試,嗯?是怎樣?好吧,View Controller 是出了名的難以測試,因為它們做了太多事情。在 MVVM 裡,我們試着盡可能多的将代碼移入 View Model 裡。測試 View Controller 就變得容易多了,因為它們不再做一大堆事情,并且 View Model 也非常易于測試。讓我們來看看:
SpecBegin(Person)
NSString *salutation = @"Dr.";
NSString *firstName = @"first";
NSString *lastName = @"last";
NSDate *birthdate = [NSDate dateWithTimeIntervalSince1970:0];
it (@"should use the salutation available. ", ^{
Person *person = [[Person alloc] initWithSalutation:salutation firstName:firstName lastName:lastName birthdate:birthdate];
PersonViewModel *viewModel = [[PersonViewModel alloc] initWithPerson:person];
expect(viewModel.nameText).to.equal(@"Dr. first last");
});
it (@"should not use an unavailable salutation. ", ^{
Person *person = [[Person alloc] initWithSalutation:nil firstName:firstName lastName:lastName birthdate:birthdate];
expect(viewModel.nameText).to.equal(@"first last");
it (@"should use the correct date format. ", ^{
expect(viewModel.birthdateText).to.equal(@"Thursday January 1, 1970");
SpecEnd
如果我們沒有将這個邏輯移入 View Model,我們将不得不執行個體化一個完整的 View Controller 以及伴随的 View,然後去比較我們 View 中 Lable 的值。這樣做不隻是會變成一個麻煩的間接層,而且它隻代表了一個十分脆弱的測試。現在,我們可以按意願自由地修改視圖層級而不必擔心破壞我們的單元測試。使用 MVVM 帶來的對于測試的好處非常清晰,甚至從這個簡單的例子來看也可見一斑,而在有更複雜的表示邏輯的情況下,這個好處會更加明顯。
注意到在這個簡單的例子中, Model 是不可變的,是以我們可以隻在初始化的時候指定我們 View Model 的屬性。對于可變 Model,我們還需要使用一些綁定機制,這樣 View Model 就能在背後的 Model 改變時更新自身的屬性。此外,一旦 View Model 上的 Model 發生改變,那 View 的屬性也需要更新。Model 的改變應該級聯向下通過 View Model 進入 View。
在 OS X 上,我們可以使用 Cocoa 綁定,但在 iOS 上我們并沒有這樣好的配置可用。我們想到了 KVO(Key-Value Observation),而且它确實做了很偉大的工作。然而,對于一個簡單的綁定都需要很大的樣闆代碼,更不用說有許多屬性需要綁定了。作為替代,我個人喜歡使用 ReactiveCocoa,但 MVVM 并未強制我們使用 ReactiveCocoa。MVVM 是一個偉大的典範,它自身獨立,隻是在有一個良好的綁定架構時做得更好。
<a target="_blank" href="http://objccn.io/issue-13">話題 #13 下的更多文章</a>
關于譯者
朱宏旭
留着長發的NIX,用過幾年Linux,目前做 iOS 開發。喜歡科幻小說和科幻電影,因為幻想和夢境能帶給我異世界體驗。偶爾半夢半醒之間會質疑人生的意義,不知活着的所謂。
<a target="_blank" href="https://twitter.com/nixzhu">https://twitter.com/nixzhu</a>