Просмотр полной версии : [PureMVC] Стоит ли изучать pureMVC?
знаю и пользуюсь успешно Cairngorm
вот появилось немного свободного времени и решил подучится. Стоит ли изучать pureMVC? Можно ли выделить какие-то бесспорные преимущества перед Cairngorm?
Спасибо
terbooter
14.10.2009, 09:57
Cairngorm не знаю. Но читал на форуме pureMVC множество дискуссий между создателями этих фрэймворков.
Мое мнение pureMVC изучить стоит.
К тому же, он проще Cairngorm-а, а значит, вы быстро в нем разберетесь.
хм, глядя на схему pureMVC с его медиаторами, фасадом и прочим, мне кажется что он явно не будет легче.
Наоборот Cairngorm - простой инструмент как топор :)
Не стоит. Как и Cairngorm.
DarkLight
14.10.2009, 16:25
К тому же, он проще Cairngorm-а, а значит, вы быстро в нем разберетесь.
Ну если посмотреть Cairngorm 3, в который свалили все, что только могли - то может и да. Классический Cairngorm 2.x вполне удобный, часто пользуюсь. Я не вижу смысла в использовании PureMVC, мне он кажется нелогичным и способствующим сваливанию неопределенного кода в фасаде.
Не стоит. Как и Cairngorm.
про Cairngorm уже поздно ))
а почему вы так считаете?
а почему вы так считаете?
Падает уровень разработчика.
Сейчас переписываю проект сделаный с использованием Cairngorm... Первая мысль: мама, какой же это мрак... Вторая мысль: и зачем же это все кому-то нужно?
Как для человека непосвященного сие чудо выглядит примерно так: "а давайте возьмем огромную неповоротливую машину - RemoteObject, размножим ее в невероятном количестве, навешаем на нее сверху еще по столько же, а то и больше всякой лабудени и все это для того, чтобы не использовать NetConnection, просто потому, что NetConnection - это фи! примитив!"
Это ж в каких сумерках человеческого разума это чудо было зачато...
terbooter
15.10.2009, 09:04
OTE]
... PureMVC, мне он кажется нелогичным и способствующим сваливанию неопределенного кода в фасаде.
Этим pureMVC точно не страдает =)
Но зато он склонен к переносу логики в медиаторы.
Это да. Убедился на своем опыте и народ на офф форуме тоже говорит.
Падает уровень разработчика.
Да кстати я стал уже беспокоится по поводу того, что не могу мыслить иначе как не по карнигорновски... Наверное нужно быть гибче :).
Но все равно, эти фреймворки появились не потехи ради. Они действительно помогают в разработке...
все это для того, чтобы не использовать NetConnection
в Cairngorm вообще сложно грамотно встроить NetConnection и NetStreams. Смотрел пример чата на Cairngorm, но мне показалось что можно(или нельзя) реализовать это все красивее.
Как бы это так сказать, NetConnection очень глубоко похоронен в структуре каирнгорма...
Т.е. так для общего представления, что происходит, когда вы вещаете каирнгормовское событие:
Оно попадает в локатор -> локатор дергает команду -> команда дергает remote object -> remote object дергает флексовый класс server -> класс server запускает еще с дюжину разных никому не нужных операций и в итоге мы добираемся до NetConnection или URLLoader и посылаем запрос, возможно, состоящий всего из пары байт... Схема не принимает во внимание всякие заковыристости флексового биндинга, и то так и сколько всякой абсолютно ненужной ерунды произойдет по дороге...
Но главное, что все это абсолютно не нужно... Т.е. номинально это нужно для того, чтобы якобы облегчить разработку, но, на практике АПИ NetConnection или URLLoader - простые как палка и работают, на сколько это можно быстро и с небольшим количеством багов... С другой стороны, весь этот хлам с красивыми названиями работает очень нестабильно, медленно, дебажить его практически нереально из-за идиотов-разработчиков которые насовали туда анонимных функций и их все еще в try-catch завернули...
Это просто какое-то увлечение модной фишкой... написать кучу всякого красиво оформленного Г. и с помпой это преподнести, а потом долго думать, как же и чего с этим делать...
DarkLight
16.10.2009, 01:23
Хм, ну анонимные функции и try-catch это не вина Cairngorm-а) А дебажить код такого плана легче, чем простыню из 3000+ строк, т к хоть зачатки логики раскладки на команды есть почти всегда)
Как бы фишка в том, что когда руководствуясь лучими побуждениями разработчики этого замечательного продукта писали что-то в духе:
try {
// this function may be undefined
someFunction.apply(foo, [...]);
}
catch
{
// well, it was undefined, we'll check back later...
}
То просто руки опускаются что-то дальше с этим делать... как по мне, 3000, да хоть 30000 строк, если там нету однозначного бреда, будет проще переварить чем пытаться выяснить на каком этапе в someFunction случилась ошибка...
чем простыню из 3000+ строк
Ооо, если не PureMVC, то не ООП, а значит простыни? Клево.
Падает уровень разработчика.
В чём конкретно проявляется уровень падения?
DarkLight
16.10.2009, 18:11
Ооо, если не PureMVC, то не ООП, а значит простыни? Клево.
Во-первых, я вообще не про PureMVC. Идея в том, что *****код, построенный на архитектурном фреймворке в общем случае легче разбирать, чем *****код, построенный без него. Тот же Flex Framework (2-3), который мозг сломаешь пока разберешь.
Я не считаю что изучение архитектурного фреймворка снижает уровень разработчика, так как для малых/средних проектов их использование экономит время - этап проектирования архитектуры ужимается в несколько раз без особого вреда для конечного результата. В случае команд с частой сменой разработчиков без преемственности, что встречается вокруг да около, аналогичная ситуация - хотя бы часть логики автора на поверхности.
Nemo_c, в том, что реализовать своё MVC потом всё труднее и труднее.
DarkLight, его одинаково хреново разбирать, если это *****код. Ещё печальнее, если он юзает фреймворк.
DarkLight
16.10.2009, 22:03
реализовать своё MVC потом всё труднее и труднее.
А конструкторам автомобилей ездить на чужих не следует, потому что проектировать машину все труднее и труднее?:D
Наоборот, мы видим в перспективе: если использовать такую-то архитектуру, на таком-то этапе возникают неудобства, соответственно надо предусмотреть, чтобы у себя такого не было.
Фишка как раз в том, что когда проблема случается в фреймворке, особенно, типа Флекс / Каирнгорм и т.п. То только на локализацию и выяснение, а что собственно произошло уходят иногда недели... и объяснить человеку, которому этот *****код состряпали за пару дней, что найти и ликвидировать ошибку будет очень сложно - сами понимаете... Фреймворк должны писать и тестировать куча талантливых програмистов, чтобы эта штука была пригодна к применению... а наши АС3 "фреймворки" соотносятся с нормальными разработками, как "Рабинович по телефону напел" с Бетховеном :)
Не ходя далеко за примером:
try
{
var result:Object = wrappedFunction.apply(thisArg, args);
wrappedFunctionSuccessful = true;
return result;
}
catch(itemPendingError:ItemPendingError)
{
itemPendingError.addResponder(new EvalBindingResponder(this, object));
if (BindingManager.debugDestinationStrings[destString])
{
trace("Binding: destString = " + destString + ", error = " + itemPendingError);
}
}
catch(rangeError:RangeError)
{
if (BindingManager.debugDestinationStrings[destString])
{
trace("Binding: destString = " + destString + ", error = " + rangeError);
}
}
catch(error:Error)
{
// Certain errors are normal when executing a srcFunc or destFunc,
// so we swallow them:
// Error #1006: Call attempted on an object that is not a function.
// Error #1009: null has no properties.
// Error #1010: undefined has no properties.
// Error #1055: - has no properties.
// Error #1069: Property - not found on - and there is no default value
// We allow any other errors to be thrown.
if ((error.errorID != 1006) &&
(error.errorID != 1009) &&
(error.errorID != 1010) &&
(error.errorID != 1055) &&
(error.errorID != 1069))
{
throw error;
}
else
{
if (BindingManager.debugDestinationStrings[destString])
{
trace("Binding: destString = " + destString + ", error = " + error);
}
}
}
Вот это достижение человеческого гения... (Это класс Binding, который используется во флексовом фреймворке на каждом шагу). Вот забиндили вы сеттер с ошибкой, ну и ищите его теперь по всему приложению...
DarkLight, опираться на опыт, безусловно, необходимо, но головой всё же нужно думать своей, а не исправлять впоследствии недостатки чужой.
DarkLight
17.10.2009, 00:32
типа Флекс / Каирнгорм
Ну флекс это частный случай и жесть страшная, все сводится к тому, что в проекте, его использующем, количество немодифицированного кода и родных компонентов стремится к нулю:)
но головой всё же нужно думать своей, а не исправлять впоследствии недостатки чужой.
Ну это никто и не отрицает) Меня удивило категоричное утверждение о ненужности и вредности изучения продуктов чужих голов.
Ну это никто и не отрицает) Меня удивило категоричное утверждение о ненужности и вредности изучения продуктов чужих голов.
Изучить — можно. Использовать — нет.
Изучить — можно. Использовать — нет.
вы приверженец велосипедов?
вы приверженец велосипедов?
В смысле изобретать? Нет, я приверженец наличия мозга у разработчика. PureMVC не является тем самым изобретенным велосипедом (несмотря на название) вовсе. Наоборот, это не велосипед, у которого три колеса разного диаметра, педаль только с одной стороны, нет сидения и руль под углом 90 градусов.
PureMVC не является тем самым изобретенным велосипедом (несмотря на название) вовсе.
Денис, аргументируйте свой ответ более детально, плиз.
Для реализации MVC не нужно навешивать огромное количество шаблонов вроде команд, медиаторов и фасадов, а этого добра в PureMVC валом, причем оно вовсе не нужно. Лучше сделать древовидную структуру моделей, контроллеров и вьюверов, чем навешивать к единственным трем синглтонам кучу непонятных приблуд.
Для реализации MVC не нужно навешивать огромное количество шаблонов вроде команд, медиаторов и фасадов, а этого добра в PureMVC валом, причем оно вовсе не нужно. Лучше сделать древовидную структуру моделей, контроллеров и вьюверов, чем навешивать к единственным трем синглтонам кучу непонятных приблуд.
+9000
Самое что не понравилось мне в pureMVC - это синглтоны и отсутствие древовидности в MVC структуре..
Кроме того использование собственного диспатчера ( или как там он называется) тоже мне непонтно.. понятно что это порт с явы, и там он называется так, но всё равно нафик?
chatlano
28.10.2009, 20:40
+9000
Самое что не понравилось мне в pureMVC - это синглтоны и отсутствие древовидности в MVC структуре..
Кроме того использование собственного диспатчера ( или как там он называется) тоже мне непонтно.. понятно что это порт с явы, и там он называется так, но всё равно нафик?
А не могли бы по поводу древовидности написать более развернуто, чтоб было понятно что конкретно имеется в виду.
Под "диспатчером" вы подразумеваеете notifications наверное? Они нужны для того чтобы не привязывать framework к конкретной технологии/языку. PureMVC портирован под разные: php, javascript etc.
Я использовал в работе как cairngorm так и pureMVC. Для меня pureMVC являеется намного более логичным и простым инструментом чем carngorm. Не говоря уже о том что количество документации и ее качество выше чем у cairngorm. PureMVC существуте в двух версиях а именно singleCore и multeCore. В multeCore сингтонов нет, там мультитоны :) Есть так же очень интересная штука под названием finite-state machine - это реализация конечного автомата. С ее помощью я в своем проекте смог динамизировать и выделить отдельно в xml файлы управление поведением в каталоге в зависимости от настроек.
Мой совет как минимум изучить.
Жду коментриев Котяры и etc-а, может быть они мне растолкуют о древовидности и я забуду о pureMVC как о страшном сне :)
DarkLight
28.10.2009, 21:16
pureMVC являеется намного более логичным и простым инструментом чем carngorm
Тут, как мне кажется, субъективно, того небольшого количества документации по Cairngorm спокойно хватает, чтобы разобраться в нем.
Кроме того использование собственного диспатчера ( или как там он называется) тоже мне непонтно.. понятно что это порт с явы, и там он называется так, но всё равно нафик?
А почему нет? Вполне правильный подход, на мой взгляд, чтобы четко разделять, что от фреймворка, а что родное.
Нет-нет, продолжайте смотреть ужасы.
chatlano
02.11.2009, 18:14
Тут, как мне кажется, субъективно, того небольшого количества документации по Cairngorm спокойно хватает, чтобы разобраться в нем.
Фразой "для меня" я подчеркиваю субъективность моего высказывания, поэтому казаться ничего не должно :) Я участвовал в проекте в котором ухитрились в Cairngorm не разобраться и использовали не правильно. Как результат пришлось переписывать годичную работу с 0ля. Не могу утверждать что те же люди разобрались бы в pureMVC но по крайней мере возможности менять модель из view у них бы не было.
to __etc
А вы не могли бы дать ссылки на то что вы подразумеваете под "развитой древовидностью"? Я не для стеба интересуюсь а чтобы сложить о вопросе свое собственное мнение.
На всякий случай: я не являюсь фанатом pureMVC или другого framework и не собираюсь начинать священных войн. У меня есть опыт работы с cairngorm и pureMVC и по результатам я написал свое мнение на данный момент времени. Вы pureMVC критикуете и предлагаете другой подход но без конкретики. Я бы с удовольствием изучил какую-нибудь конкретику, чтобы понять почему "Лучше сделать древовидную структуру моделей, контроллеров и вьюверов, чем навешивать к единственным трем синглтонам кучу непонятных приблуд."
http://www.flasher.ru/forum/showthread.php?t=131588
Работает на vBulletin ® версия 3.7.3. Copyright ©2000-2026, Jelsoft Enterprises Ltd. Перевод: zCarot
Copyright © 1999-2008 Flasher.ru. All rights reserved.