iOS：模型 - 應用程序中的體系結構

我確實爲這個主題找到了一些建議，但仍然有一些東西對我開放。iOS：模型 - 應用程序中的體系結構

問題是關於設計一個應用程序（從發展的角度來看），特別是關於模型。

例如，我正在用Facebook SDK構建應用程序。我想有一個與Facebook API交流的模型類是有意義的。而且我猜這樣做會讓這個類變成單例（不一定是）。

但是面向iOS的Facebook SDK建立在委託之上。因此，您發送一個請求，並將響應返回到模型中的委託方法中。沒關係，但我也想分配一個委託給模型，以便視圖控制器被調用。

因此，例如，視圖控制器使用Facebook單例模型發出請求，但希望將自己設置爲此請求的委託，以便模型在請求完成時調用此委託。但是這個模型是一個單例，它只有一個代表（我希望它保持這樣）。那麼在每次調用之前，我是否會覆蓋Facebook單例中的委託指針？（不好，因爲另一個請求可能在同一時間使用同一個單例開始，委託將被重寫）。

那麼什麼是好的建築？在整個應用程序中重複使用模型的最佳實踐是什麼？

來源

2011-12-21 cmart

最後我用單身的我的模型與得到一個sharedInstance（單身）

+(QuizManager *)sharedInstance 
{ 
    static dispatch_once_t pred; 
    static QuizManager *shared = nil; 

    dispatch_once(&pred, ^{ 
     shared = [[QuizManager alloc] init]; 
    }); 
    return shared; 
}

偉大的工作，以下線程安全的代碼確實很好，也關鍵 - 價值 - 的使用在iOS中觀察（KVO）。我可以觀察模型中屬性的變化，並在視圖控制器中作出反應。海事組織這允許創建非常乾淨和易於理解的代碼。（查看它並喜歡它：http://developer.apple.com/library/ios/#documentation/cocoa/conceptual/KeyValueObserving/KeyValueObserving.html）

在一點上，我也使用一個模型，並將其設置爲一個代表，並給它一組代表，而不是將代表方法廣播給所有觀察者，我發現也很好。

來源

2012-01-08 08:43:46 cmart

我的建議是創建您自己的委託協議並將viewControllers註冊爲您的單例模型的委託。你可以在很多方面自由地做到這一點，你可以有多個委託（通過將代表保存在單例中的數組中）。

來源

2011-12-21 13:27:08

我的Facebook模型已經有了一個自定義協議，它又被另一個模型使用。所以實際上它是視圖控制器 - >用戶管理模型 - > Facebook模型。這使得整個委託工作不容易.. – cmart

iOS：模型 - 應用程序中的體系結構

回答

相關問題