Хорошее MVC

[Zebestov]

Сразу говорю: MVC — только разбираюсь, UML — вообще никогда не ругайте.
Вот набросал схемку:

[IMG]http://s39.***********/i086/1009/9b/39f0a12eb88f.jpg[/IMG]

Допустим решил я сделать Menubar.

Model хранит массив кнопок (id, title)

View рисует все кнопки, что есть в Model, по событию CHANGE.

Controller запрашивает у API сервера (через другой контроллер — APIController) список доступных пользователю кнопок, парсит ответ и записывает в модель уже в виде требуемого массива. Также по нажатию на кнопку контроллер получает id кнопки и предпринимает определенные действия.

Обращение к API происходит вызовом метода APIController#request(req:String):APILoader, т.е. мы подаем запрос в неком универсальном формате (например синтаксис Facebook Graph API нравится), метод создает новый APILoader (расширяет наверное URLLoader) и возвращает его, чтобы основной контроллер мог подписаться на его COMPLETE и взять именно свою data по факту загрузки.

Что правильно, что ошибка, что чушь по неопытности — хочу как-то разобраться в этом вопросе основательно.

[etc]

Непонятна роль APIController-а. Точнее понятна, но результат парсить должен именно он и выдавать его уже в виде удобоваримых данных MenubarController-у. Либо парсить должна сама модель. И возвращать APILoader не имеет смысла, слушать его должен сам APIController, а по окончании загрузки слать событие COMPLETE. Сейчас в APIController получается единственный метод, содержащий три строчки.

[Tr1te]

Не понимаю зачем сонтроллеру передавать ссылку на себя моделе и вьюверу, если они являются детьми и они могут к нему обращаться как

parent.

?

[etc]

Tr1te, модель ничего не знает о контроллере и вьювере, если что. А обращение к родителю в принципе не есть ООП-подход.

[Obi]

Простите за оффтоп, но прицепите уже эту тему вверх раздела. Полезность ее зашкаливает.

[etc]

Сообщение от Obi

Простите за оффтоп, но прицепите уже эту тему вверх раздела. Полезность ее зашкаливает.

Done.

[Zebestov]

Сообщение от etc

Непонятна роль APIController-а. Точнее понятна, но результат парсить должен именно он и выдавать его уже в виде удобоваримых данных MenubarController-у. Либо парсить должна сама модель.

Предполагалось, что APIController — это общий для всего приложения класс, задача которого обеспечивать запросы к API серверу текущей среды (vkontakte, facebook и также просто сайт приложения в сети интернет). Он единственный знает (при инициализации), в какой среде сейчас запущено приложение и делает выборку нужных данных соответствующим образом. Поэтому, в силу отличий API разный сетей, для запросов к нему внутри приложения формируется некий универсальный формат. То же для ответов.
Вот теперь больше информации о том, что я хочу сделать. Все очень сырое и совет/отбраковка приветствуются.
Из всего этого я подумал, что APIController парсить ничего не должен. Да и слово парсить наверное громко для процесса из моей схемы... это скорее выборка только нужных данных для MenubarModel, который сейчас должен иметь по каждому пункту меню только его id и title. Вот такой был ход мысли.

Насчет "парсить в модели". По сути модель тоже в праве знать о формате ответов на API запросы, принятом в приложении, чтобы самостоятельно разобрать вошедший Object и сохранить в себе только нужное. Так будет правильней? (а то она вообще тогда какая-то вот-вот нафиг ненужная)

И возвращать APILoader не имеет смысла, слушать его должен сам APIController, а по окончании загрузки слать событие COMPLETE.

Единственная причина такой схемы — обеспечить ожидание именно своих данных в случае, когда к APIController-у обратится подряд несколько контроллеров каждый со своим "заказом". Ведь если слушать COMPLETE самого APIController, то поди разбери чей это ответ пришел? Не ну можно придумать схему разбора по какому-то requestID, который возвращал бы метод request() (сейчас он возвращает ссылку на APILoader). Так будет правильней?

Сейчас в APIController получается единственный метод, содержащий три строчки.

Ну выше я уже описал, что по сути внутри у APIController целый механизм, ограждающий приложение от среды с ее особенностями.

Спасибо за ответы! Надеюсь разобраться с вашей помощью.

[etc]

Zebestov, тогда APIController должен отдавать в универсальном формате, скажем, в виде экземпляра какого-нибудь универсального APIUserData. Парсить — это к примеру из xml/json в этот самый APIUserData. В модель можно сувать через addAPIUser.

Кроме того, не вижу никакого смысла делать запросы к нему из нескольких мест, этим должен заниматься основной контроллер приложения, а APIController в ответ будет вызывать методы в нём (через client).

[Zebestov]

Сообщение от etc

Кроме того, не вижу никакого смысла делать запросы к нему из нескольких мест, этим должен заниматься основной контроллер приложения, а APIController в ответ будет вызывать методы в нём (через client).

Чувствую, что что-то правильное, но ничего вообще не могу разобрать =(
Запросы из нескольких мест — это в плане передавать APIController (один из основных контроллеров приложения) ссылкой в контроллеры для того, чтобы они могли вызывать его request()? Т.е. так делать не годится?

[etc]

А зачем? Где такая ситуация может возникнуть? Максимум дочерний контроллер попросит основной загрузить что-нибудь. После загрузки все и так попадет в модель, поэтому и заниматься обработкой данных дочернему контроллеру никакого смысла нет, ему необходимо лишь наблюдать за моделью.