Форум Flasher.ru

Форум Flasher.ru (http://www.flasher.ru/forum/index.php)
-   Статьи (http://www.flasher.ru/forum/forumdisplay.php?f=101)
-   -   Хорошее MVC (http://www.flasher.ru/forum/showthread.php?t=138349)

Zebestov 10.09.2010 04:48

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

[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 10.09.2010 11:56

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

Tr1te 10.09.2010 13:11

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

parent.
?

etc 10.09.2010 13:14

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

Obi 10.09.2010 13:29

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

etc 10.09.2010 13:31

Цитата:

Сообщение от Obi (Сообщение 934823)
Простите за оффтоп, но прицепите уже эту тему вверх раздела. Полезность ее зашкаливает.

Done.

Zebestov 10.09.2010 14:03

Цитата:

Сообщение от etc (Сообщение 934785)
Непонятна роль 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 10.09.2010 14:34

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

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

Zebestov 10.09.2010 14:49

Цитата:

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

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

etc 10.09.2010 14:58

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


Часовой пояс GMT +4, время: 20:43.

Copyright © 1999-2008 Flasher.ru. All rights reserved.
Работает на vBulletin®. Copyright ©2000 - 2026, Jelsoft Enterprises Ltd. Перевод: zCarot
Администрация сайта не несёт ответственности за любую предоставленную посетителями информацию. Подробнее см. Правила.