Comments 19
А почему у вас первый рисунок (схема) идет под номером 4? Или это описание, под ним все таки четвертого рисунка по счёту от первого в статье?
Ага. Перевод выкладываю кусками, по мере готовности.
Это понятно, но раз подпись находится под рисунком то к чему информация какой это по счёту рисунок?
В статье так.
Какое это отношение имеет к вашей публикации? Вы уже поменяли формат, разбив ее на части и тем самым нарушили логику…
Объясните мне пожалуйста последний пункт. Написано, что представление и контроллеры не должны взаимодействовать друг с другом. Как тогда работают контроллеры я не понимаю. Контроллер должен как-то узнать, что изменился текст в текстовом поле, например. Как он это узнает? Ведь это через контроллер в модель должны попадать данные.
Отличная статья :)
Если хотя бы одно приложение станет чище и читабельнее после этого, это уже достаточное основание, чтобы переводить и публиковать.
Спасибо.
Если хотя бы одно приложение станет чище и читабельнее после этого, это уже достаточное основание, чтобы переводить и публиковать.
Спасибо.
Сори. Старался переводить как можно ближе к тексту, отсюда такая рубленность.
Я в своё время сделал компромиссный вариант MVC на основе образца Observer для J2ME-приложения. Может кто выскажет критические замечания моему подходу, буду признателен.
Почему «компромиссный»? Потому что не все тулкиты позволяют реализовать «правильный» MVC из-за каких-либо ограничений архитектуры базовых библиотек.
Вот простенькая интерпретация того, что получилось.
Модель представляла собой, пользуясь терминологией статьи, «Доменный объект», связанный с Представлениями только событийным интерфейсом (Представления «подписывались» на событие изменения состояния Модели). Модель имела свою собственную линию жизни (нить исполнения, thread) и не зависела ни от чего другого, жила своей жизнью — эволюционировала, так сказать, с определёнными параметрами (скорость движения, направление движения и текущие координаты). При изменении координат рассылалось уведомление всем «подписчикам» — Представлениям.
Другая часть — «Модель представления» (Presentation model, пользуясь терминологией статьи) — «зашита» в объект формы «Настройки». Устанавливает скорость в Модели после подтверждения ввода пользователя. Это данные «сессии» (см. первую часть статьи).
Контроллёр по идее должен был контролировать все нажатия клавиш и управлять Моделью (менять её состояние). Но все события от клавиатуры перехватываются базовым элементом Canvas (графическим Экраном) — так решили разработчики платформы J2ME — а транслировать команды управления в Контроллёр (мидлет) накладно и неэффективно, поэтому состояние Модели (направление движения и скорость) задавалось в коде объекта-потомка Canvas в зависимости от нажатых клавиш.
Вот, в общем-то, простейшая концептуальная реализация одной из видений MVC. Критикуйте.
Почему «компромиссный»? Потому что не все тулкиты позволяют реализовать «правильный» MVC из-за каких-либо ограничений архитектуры базовых библиотек.
Вот простенькая интерпретация того, что получилось.
Модель представляла собой, пользуясь терминологией статьи, «Доменный объект», связанный с Представлениями только событийным интерфейсом (Представления «подписывались» на событие изменения состояния Модели). Модель имела свою собственную линию жизни (нить исполнения, thread) и не зависела ни от чего другого, жила своей жизнью — эволюционировала, так сказать, с определёнными параметрами (скорость движения, направление движения и текущие координаты). При изменении координат рассылалось уведомление всем «подписчикам» — Представлениям.
Другая часть — «Модель представления» (Presentation model, пользуясь терминологией статьи) — «зашита» в объект формы «Настройки». Устанавливает скорость в Модели после подтверждения ввода пользователя. Это данные «сессии» (см. первую часть статьи).
Контроллёр по идее должен был контролировать все нажатия клавиш и управлять Моделью (менять её состояние). Но все события от клавиатуры перехватываются базовым элементом Canvas (графическим Экраном) — так решили разработчики платформы J2ME — а транслировать команды управления в Контроллёр (мидлет) накладно и неэффективно, поэтому состояние Модели (направление движения и скорость) задавалось в коде объекта-потомка Canvas в зависимости от нажатых клавиш.
Вот, в общем-то, простейшая концептуальная реализация одной из видений MVC. Критикуйте.
черт, мозг сломал. дайте кто-нить для нуба mvc ссылку (mvc я понимаю, но какие задачи ставились и для чего был нужен — не врублюсь)
Sign up to leave a comment.
Martin Fowler — GUI Architectures. Часть 2