Ваша реализация MVC

[dimarik]

Так-с, про XML уже сказали. Жду когда расскажут про агрегатирование.

[Babylon]

Сообщение от Psycho Tiger

Тот же концепт даст пустой метод в классе, без реализации классом интерфейса.

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

Добавлено через 10 минут
dimarik, пожалуйста конкретизируйте свой вопрос.

Добавлено через 25 минут

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

Та да:
А вот это вообще набор слов:
Или это и есть "Ваша реализация MVC"? Тогда, пожалуйста, подробней.

Я то как раз за минимизацию использования интерфейсов. Но когда компоненты MVC разрабатывают разные люди наверно он необходим. Я даже в этом уверен. И повторяю - это не сравнение это следствие расширения функциональности. Посмотрите на Drupal. Его ядро только увеличивается и это плюс, а не минус. Вторым плюсом является использование механизма entity reference и типов сушностей - бандлов. На которых и строится агрегатирование. Понятно, что идейно всё это идет от Java, но в AS3 и близко этого нет.

Добавлено через 36 минут

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

Интересно, сколько у вас событий, что бабблинг тормозит?

Вы знаете не считал. Это было изначально не мое приложение.

[dimarik]

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

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

Вот и дорассуждались. Демагогия.

[Babylon]

okouser, инжекции заменяют один класс другим так чтобы Вы этого не заметили. При чем тут чистота кода? Что Вы собирайтесь менять в ядре??? И если уж соберетесь, то это затронет и интерфейсы и все классы которые его имеют. Извините за демагогию. Я не воспитан в ТЗ и слава Богу.

Добавлено через 5 минут
Я полностью разделяю точку зрения автора http://javascript.ru/optimize/antimvc
Роль DOM может играть XML

[Babylon]

на другой реализации интерфейса... Умом не понять. Моим. Интерфейсы нужны чтобы одна часть системы - ваша понимала другую часть, написанную не вами. Для этого исп. прокси, которые экстендят чужие классы и реализуют нужный интерфейс понятный вам. Какие инициализации вы о чем?

Бизнес-логика... Я про нее и не думал, а Вам почему то икнулось. Где я заменяю MVC на XML? Но в конструкторы видов и сервисов я действительно передаю xml ноды. Виды легко могли бы менять модель без С если бы не сервер... Так что контролер нужен а значит и MVC.
Можете меня считать демагогом, плотником или каменщиком.

[Zebestov]

Настаиваю на прекращении рассуждений на предмет целесообразности MVC как такового и высказываться все же в рамках названия темы: "Ваша реализация MVC"

[namespaces]

"Ваша реализация MVC" - это типа с нуля создать свое с пересозданием существующих известных фреймворков? Кто по вашему будет на это тратить время, если помимо проекта и архитектуры еще предстоит возня с интерфейсом, дизайном, логикой, тестированием, отладкой приложения?!
Можно было бы скопирнуть сюда свои кастомные классы, если вы имели ввиду только как "Ваше понимание MVC", нежели "Ваша реализация". Т.к. написание фреймворка это не только завернуть все в пакетик SWC и продолжать творить по этому шаблону.
Каждый проект это новый MVC.

ps Ничего дельного не сказал, но ухх как высказался)) полегчало.

[Isfet]

почитав темы про mvc я понял что структура вьювов должна почти зеркально повторять структуру моделей,
но если нажали что-нибудь во вью, а она находится глубоко, а контроллера нет поблизости, передаем событие ближайшему контроллеру, но как этот контроллер может дать своей модели какую именно модель внутри нее нужно изменить(то есть как найти можель которая принадлежит именно этой вью ), вижу два варианта:
1. использовать метки (типо айдишников в БД).
2.все же создавать триаду "на глубине", и тогда контроллер будет знать к какой модели относится вью.

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


также не понятно каким образом удаляется триада во втором случае (2.все же создавать триаду, и тогда контроллер будет знать к какой модели относится вью.)

мне видится такое удаление:

1. вью диспатчит "removeMe",
2. его контроллер ловит событие, и вызывает у модели destruct.
3. модель диспатчит верхней модели "removeModel", так как у верхней модели есть ссылка на нее и ссылку надо удалить.
4. также это "removeModel" ловит вью удаляет слушатели и диспатчит событие для верхней вью, чтобы она ее удалила.
5.контроллер удаляет слушатели и диспатчит событие верхнему контроллеру , чтобы он его удалил(есть ссылка).

просьба строго не судить) я пытаюсь понять суть)

[Babylon]

У каждой модели (ноды) как и вида должен быть id по которому контроллер узнает ее инстанс
Вид рендерится виджетами по модели, а контроллер обрабатывает их взаимодействие посредством событий.

[Isfet]

получается что каждый вью хранит айди модели?
то есть получается порядок действий такой?
1. кликнули на вью,
2. диспатчим кастом событие, в котором передаем айди вью,
3.контроллер находит этот вью по айди
4. вытаскивает из него данные и айди модели
5.говорит модели записать данные во внутреннюю модель по айдишнику

так?