MVC с какао / объектив-с

Question

У меня сильный опыт работы с j2ee, и я пытаюсь перейти на target-c для некоторых программ для настольных компьютеров / iphone.

Я использовал множество веб-фреймворков Java с учетом mvc, Spring и Struts и т.д. ... поэтому я привык иметь сервлет или контроллер, которые передают атрибуты страницам jsp, то есть представлению. На страницах jsp с jstl вы можете вызвать этот атрибут и выполнить рендеринг в видео. Таким образом, контроллер и представление (в теории) четко разделены.

С помощью xcode я могу легко распознать контроллер и представление, созданное с помощью IBuilder. Все учебники, которые я нашел, показывали контроллер, который идет и меняет непосредственно метки или текстовые поля.

Итак, мои два вопроса:

1. мне кажется, что нет никакого разделения между ними (контроллером и представлением), где я неправ в этом?
2. Есть ли способ для контроллера упаковать все объекты в некоторый контекст в виде j2ee и иметь представление, читающее этот контекст?

спасибо Leonardo

Answer 1

Я не понимаю ваш второй вопрос (я никогда не использовал J2EE), но я думаю, что смогу хоть как-то ответить на ваш первый.

Какао не обеспечивает MVC;это только сильно поощряет это - особенно для больших проектов.Рассмотрим пример программы, в которой NSTableView привязан к NSArrayController.

В этом случае NSTableView - это явно представление (в его названии есть слово «представление»), а NSArrayController - это явно контроллер(в его названии есть слово «контроллер»).

Модель представляет собой NSArray, о котором знает NSArrayController, но вы, вероятно, не взаимодействуете с этой моделью напрямую.Вместо этого вы попросите NSArrayController манипулировать его моделью, отправив сообщения addObject: и removeObject: контроллеру массива (а не самому массиву).

Когда вы сделаете это, NSArrayController произведет изменение в NSTableView через привязки.Опять же, вы никогда не просите NSTableView что-либо сделать.

То есть вы никогда не разговариваете с представлением и никогда не разговариваете с моделью.Все, что вы хотите, проходит через контроллер.

MVC.QED.

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

Answer 2

В большинстве примеров, которые вы читали, вы, вероятно, видели что-то вроде этого:

[myTextfield setStringValue:myString];

теперь в этом случае убедитесь, что контроллер обновляет текстовое поле напрямую, однако, поскольку myTextfield обычно является IBOutlet, это может быть любое текстовое поле в вашем представлении, или даже ноль. вполне возможно, что даже не нужно знать, что это поле NSText просто потому, что оно отвечает методу setStringValue. В этом смысле существует разделение между контроллером и представлением.

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

MVC - это немного двусмысленная концепция без четкого определения. Это может означать разные вещи для разных людей. Для меня это означает, что представление имеет представление о контроллере (через выходы или привязки), ограниченное знание модели (через привязки). Контроллер обладает полным знанием модели и ограниченным знанием вида (через розетки). Наконец, модель имеет нулевое знание вида и в идеале не знает контроллер.

Что касается вашего второго вопроса, я не использую j2ee, но я думаю, что вы можете достичь того, что вы хотите, если ваш контроллер обновит контекстный ivar (возможно, NSDictionary), а затем, по вашему мнению, свяжется с этим контекстом с помощью keypath , Однако нет никакой необходимости в том, чтобы обернуть все, привязки очень гибки, и вы можете привязать к любому свойству.