Ваши данные становятся источником данных табличного представления, и, хотя в этом нет необходимости, контроллер представления, который содержит табличное представление, часто выполняет роль источника данных. Контроллер представления также может быть делегатом для EditViewController, поэтому EditViewController отправляет ему сообщение, чтобы он мог обновить массив.
Пример проекта Apple CoreDataBooks демонстрирует похожую архитектуру. Вы можете посмотреть.
Наличие массива в делегате приложения часто не очень хорошая идея. Хотя это может дать вам немного удобства, теперь ваши классы полностью зависят от делегата приложения без необходимости.
В табличном представлении отображаются ваши данные. Это соответствует View в шаблоне проектирования MVC. Я предполагаю, что RootViewController является контроллером представления табличного представления, которое действует как Controller в шаблоне. Ваши данные, местонахождение которых еще не определено, соответствует Модель . Роль RootViewController становится соединением Модель и Вид .
Идеал или причина шаблона MVC состоит в том, чтобы изолировать модель и представление, чтобы модель могла работать с другими представлениями с соответствующими контроллерами, а представление также могло работать с другими моделями с соответствующими контроллерами. Например, ваш RootViewController предоставит табличное представление с данными. Он будет указывать данные на языке табличного представления, например, количество секций и строк, содержимое ячеек и т. д. Если вы хотите представить данные другим способом, например, графиком, ваш контроллер получит доступ к тем же данным (модели) и предоставит представление графика в другом представлении. из тех же данных. Модель не должна меняться, как и взгляды. Вы пишете только контроллер для каждой комбинации модели и вида.
В идеале, поэтому, у вас будет другой класс для модели. В этом классе вы будете хранить массив и предоставлять общий интерфейс для контроллеров, которые могут взаимодействовать с данными.
Однако часто это не так необходимо, потому что маловероятно, что вы будете часто использовать класс модели снова, или потому что сама модель слишком проста, чтобы ее можно было легко реализовать где угодно. Например, если ваши данные для таблицы представляют собой простой массив, объекта NSArray часто достаточно для роли модели. Поэтому возникает идея, что объединить контроллер и модель в один объект .
Вот почему имеет смысл, что ваш контроллер табличного представления часто выступает в качестве источника данных табличного представления.
Однако сохранение данных в делегате приложения - это совершенно другая идея. Теперь делегат приложения становится вашей моделью, но это не имеет смысла, поскольку делегат приложения используется только для конкретного приложения. Почему у вас есть отдельный объект модели, который полностью зависит от одного приложения? Кроме того, если ваше табличное представление напрямую взаимодействует с делегатом приложения, это означает, что теперь ваше представление не может работать и для других приложений, поскольку теперь оно зависит от делегата приложения конкретного приложения.
Часто причина, по которой у людей возникает желание получить данные в делегате приложения, заключается в том, что делегат приложения легко доступен любым объектам в приложении с помощью [UIApplication sharedApplication].delegate. Отношения M-V-C не всегда очень просты. Например, ваш EditViewController также должен иметь доступ к той же модели. Для этого вам нужно написать некоторый код, чтобы сделать модель доступной как в виде таблицы, так и в режиме редактирования. Если у вас есть данные в делегате приложения, вам не нужно ничего делать, потому что вы можете волшебным образом получить доступ к массиву, обратившись к делегату приложения.
Но это все. Несколько минут экономят ваше время написания кода, поскольку вы разрушаете архитектуру программного обеспечения. Я не фундаменталист, и иногда я использую делегат приложения для хранения некоторых данных, когда я абсолютно уверен, что не стоит предоставлять правильно сформированные интерфейсы, но это редко.
Итак, как вы должны подключить свое редактируемое представление к данным, объединенным в контроллер табличного представления? Там может быть несколько способов. То, что я предлагал ранее, - это позволить контроллеру представления редактирования иметь слабую ссылку на контроллер табличного представления (delegate) и отправлять определенное сообщение, например - (void)editViewController:(EditViewController *editViewController) didFinishEditing:(id) someData. Таким образом, вы можете использовать этот контроллер представления редактирования с некоторыми другими контроллерами представления, если они используют один и тот же протокол. Но другие могут реализовать различные интерфейсы для него.