Каков наиболее подходящий шаблон для получения и настройки базовой модели данных из нескольких контроллеров представления?

Question

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

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

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

Но яне знаю, как поступить с реализацией интерфейса контроллера одной модели.Например, вот несколько идей:

• сделать этот контроллер одновременно делегатом и источником данных для всех контроллеров представления?
• должен ли контроллер быть только источником данных и использовать уведомления для обновлений?
• kvc / o?
• Является ли вся идея централизованного моста из / в модель просто сверхинженерной модели MVC?То есть, есть ли какой-то разумный аргумент в пользу того, чтобы вместо этого передавать управляемый контекст, и это не считается дерьмовым объектно-ориентированным дизайном?

Еще одна вещь, о которой я думаю, если одноэлементный контроллерделегат и источник данных, методы для получения данных модели и обновления модели должны реализовывать своего рода шаблон посетителя, верно?То есть, например, если контроллер A представления позволяет пользователю взаимодействовать с объектом / объектом A модели, а некоторый контроллер B представления допускает то же самое для объекта B модели, и оба контроллера представления полагаются на одного и того же делегата, делегат должен будетесть какой-то способ узнать, на какую модель объекта он должен нацеливаться, в зависимости от того, какой конкретный контроллер к нему обращается.

Буду признателен за любые мысли / идеи

Answer 1

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

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

Идея единого централизованного моста тоже неплоха, но это немного усложнит юнит-тестирование.

Answer 2

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

Это на самом деле не «контроллер модели», это - это модель. В MVC (традиционно) представления связываются со своим контроллером для получения рекомендаций о том, что делать с взаимодействиями, и контроллер решает, что им сказать, основываясь на своей логике и информации, которую он собирает из модели.

Так что, на самом деле, вы просто продолжаете абстрагировать модель, и это хорошо. Идея «централизованного моста» - это то, что вы хотите в MVC. Ваш контроллер должен видеть высокоуровневую абстракцию реализации базовой модели, как и со всеми интерфейсами и уровнями абстракции.

Что касается реализации модели, то , я не уверен, какой это "лучший" способ сделать это, но я не могу представить себе использование стратегии делегата / источника данных (или отправки уведомлений) для контроллера) будет вредным, я думаю, это зависит от того, что вам удобно. Если вы любите KVC / KVO, я сомневаюсь, что вам будет больно. Что касается шаблона посетителя, то логика отслеживания того, какой контроллер получает, какой объект должен находиться в модели.

Answer 3

В итоге я отказался от подхода делегирования / источника данных для одноэлементного шаблона:

Я понял следующее:

• все контроллеры сотрудничают с одним общим managedObjectContext
• Сама модель Core Data вращается вокруг одной «конфигурации» объект (не конфигурации, на которые ссылается литература Core Data к).
• Эта «конфигурация по умолчанию» также является тем, с чем взаимодействуют все контроллеры. с, так как все другие объекты существуют в контексте этого объект конфигурации.

По сути, у меня есть общий ресурс, который должен быть доступен способом, аналогичным глобальной переменной.

Итак, я инкапсулировал общий ресурс в синглтоне, через интерфейс которого все другие контроллеры могут запрашивать и модифицировать модель, не зная ничего о внутренностях.

Общий интерфейс допускает такие вещи, как:

• [ModelControllerBridge sharedBridge] defaultConfiguration] который возвращает общий ресурс по умолчанию NSManagedObject
• [[ModelControllerBridge sharedBridge] newDataSample], который возвращает новый NSManagedObject и внутренне выделяет и вставляет его в соответствующий объект в модели.
• [[ModelControllerBridge] shouldCommitChangesToModel] какие сигналы контекст должен быть зафиксирован в постоянном хранилище
• и т.д.