где хранить данные основного представления таблицы? (appDelegate или rootViewController)

Ваши данные становятся источником данных табличного представления, и хотя это не обязательно, контроллер представления, содержащий табличное представление, часто выполняет роль источника данных. Контроллер представления также может быть делегатом для EditViewController, поэтому EditViewController отправляет ему сообщение, чтобы он мог обновить массив.

Пример проекта Apple CoreDataBooks демонстрирует аналогичную архитектуру. Вы можете взглянуть.

Наличие массива в делегате приложения часто не лучшая идея. Хотя это может дать вам некоторое удобство, теперь ваши классы полностью зависят от вашего делегата приложения без необходимости.

В табличном представлении отображаются ваши данные. Это соответствует View в шаблоне проектирования MVC. Я предполагаю, что RootViewController — это контроллер представления табличного представления, который действует как Контроллер в шаблоне. Ваши данные, расположение которых еще не определено, соответствуют Модели. Роль RootViewController заключается в соединении Модели и Представления.

Идеал или причина шаблона MVC состоит в том, чтобы изолировать модель и представление, чтобы модель могла работать с другими представлениями с соответствующими контроллерами, а представление также могло работать с другими моделями с соответствующими контроллерами. Например, ваш RootViewController предоставит табличное представление с данными. Он будет указывать данные на языке табличного представления, например. количество разделов и строк, содержимое ячеек и т. д. Если вы хотите представить данные по-другому, например, в виде графика, ваш контроллер получит доступ к тем же данным (модели) и предоставит представление графика с другим представлением одних и тех же данных. Модель не должна меняться, равно как и представления. Вы пишете только контроллер для каждой комбинации модели и представления.

Поэтому в идеале у вас будет другой класс для модели. В этом классе вы будете хранить массив и предоставлять общий интерфейс для взаимодействия контроллеров с данными.

Однако часто в этом нет необходимости, либо потому, что маловероятно, что вы снова будете часто использовать класс модели, либо потому, что сама модель слишком проста, чтобы ее можно было легко реализовать где угодно. Например, если ваши данные для таблицы представляют собой простой массив, объекта NSArray часто достаточно для роли модели. Поэтому возникает идея объединить контроллер и модель в один объект.

Вот почему имеет смысл, что ваш контроллер табличного представления часто действует как источник данных табличного представления.

Однако хранение данных в делегате приложения — это совершенно другая идея. Теперь делегат приложения становится вашей моделью, но это не имеет смысла, поскольку делегат приложения используется только для конкретного приложения. Зачем вам отдельный объект модели, который полностью зависит от одного приложения? Кроме того, если ваше табличное представление напрямую взаимодействует с делегатом приложения, это означает, что теперь ваше представление не может работать и для других приложений, потому что теперь оно зависит от делегата приложения конкретного приложения.

Часто причина, по которой люди испытывают искушение иметь данные в делегате приложения, заключается в том, что делегат приложения легко доступен любым объектам в приложении с помощью [UIApplication sharedApplication].delegate. Отношения M-V-C не всегда очень просты. Например, ваш EditViewController также должен иметь доступ к той же модели. Для этого вам нужно написать некоторый код, чтобы сделать модель доступной как для табличного представления, так и для редактирования. Если у вас есть данные в делегате приложения, вам не нужно ничего делать, потому что вы можете волшебным образом получить доступ к массиву, обратившись к делегату приложения.

Но это все. Экономия нескольких минут вашего времени кодирования ценой разрушения архитектуры вашего программного обеспечения. Я не фундаменталист, и я иногда использую делегат приложения для хранения некоторых данных, когда я абсолютно уверен, что не стоит предоставлять правильно сформированные интерфейсы, но это редко.

Итак, как вы должны связать свое представление редактирования с данными, объединенными в контроллер табличного представления? Способов может быть несколько. Раньше я предлагал, чтобы контроллер представления редактирования имел слабую ссылку на контроллер табличного представления (delegate) и отправлял определенное сообщение, например - (void)editViewController:(EditViewController *editViewController) didFinishEditing:(id) someData. Таким образом, вы можете использовать этот контроллер представления редактирования с некоторыми другими контроллерами представления, если они используют один и тот же протокол. Но другие могут реализовывать для него другие интерфейсы.

Вам нужно сохранить в appDelegate, так как вы можете получить данные в любом контроллере просмотра. Но если вы используете rootviewController, тогда вы можете отправлять данные только в следующий ViewController, а не во второй или третий ViewController напрямую. Надеюсь, это поможет вам.

Удачи