один контроллер, управляющий моделью, и несколько контроллеров представления?

Question

Я работаю над приложением, имеющим несколько контроллеров представления для разных экранов, и все приложение посвящено отображению данных из базы данных sqlite.

Мой первоначальный проект состоял в том, чтобы иметь объект db (модель), главный контроллер с монопольным доступом к этой модели, а все другие контроллеры представления просто управляют визуальными аспектами окон, кнопок и всего, что у вас есть.

Но мне трудно понять, как заставить главный контроллер быть в курсе всех других контроллеров представления в течение всей жизни приложения в контексте архитектуры приложения ios от Apple.

До сих пор я думал о 3 подходах: 1 - NSNotificationCenter, а главный контроллер наблюдает за всеми другими контроллерами? 2 - сделать основной контроллер делегатом всех остальных? Хотя я до сих пор не понимаю, как определить делегируемый (я придумал это слово?) Протокол в целом. То есть даже для объектов, у которых нет метода setDelegate. 3 - передача объекта db каждому контроллеру представления. Хотя это немного похоже на игру в режиме C, проходящем вокруг ..

Есть мысли? Спасибо!

Answer 1

Ваш подход, вероятно, должен быть таким, когда контроллеры представлений и модели настолько невежественны, насколько это возможно. Я считаю, что это довольно распространенный шаблон дизайна. У вас должны быть объекты модели, которые представляют каждый логический «объект» в вашем домене. Эти объекты могут быть просто государственными. Затем вы можете захотеть создать контроллер (как вы упомянули), который имеет доступ к вашей базе данных и может выполнять запросы. Результат этих запросов должен использоваться для создания экземпляров объектов вашей логической модели (например, XXPerson) и передачи их любому, кто сделал запрос. Учитывая это, каждый контроллер представления в вашем приложении должен делать следующее:

1. Создайте свои виды и выложите их соответствующим образом
2. Создание объекта контроллера базы данных (и, возможно, удержание его для дальнейшего использования)
3. Запросите в базе данных необходимые данные через объект контроллера базы данных
4. Используйте полученные данные (которые должны быть возвращены как объекты логической модели), чтобы скорректировать представления или сделать с ними все, что вам нужно

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

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

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

Во всяком случае, это мое мнение. :)

Answer 2

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

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

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

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