Здравствуйте, adontz, Вы писали:
A>Ещё раз специально для тебя — связность это не только type declaration referencing.
Еще раз, специально для тебя.. Презентер ничего не знает о представлении кроме интерфейса. Ну что ты придирки из пальца выжимаешь, заняться нечем?
A>На основе той информации, которая IView не описывается, но тем не менее существует и повышает связность.
Ну вот откуда ты взял, что эта информация в IView не описывается?
Понимаешь, проблема в том, что ты представил себе какую-то модель в голове и пытаешься паттерн под нее подогнать, а делать надо ровно наоборот.
A>Такс, вот ты и попался великий теоритек. Реализацию в студию. И желательно без прыжков в сторону.
Ром, прыжками в сторону занимаешься исключительно ты — половину проигнорировал, все претензии свелись к "эффективности". Ну ей богу, если бы ты просто спрашивал, а не наезжал, то и глупостей меньше наговорил бы, и разобрались бы существенно быстрее.
Вот скажи мне, великий практик, что мешает Представлению, пользуясь явным контрактом IView сообщить Презентеру, какая именно порция данных нужна ему в данный момент?
Здравствуйте, ybouts, Вы писали:
Y> Как происходит взаимодействие, если у нас несколько пар presenter/view?
По разному, вариантов действительно много...
Y>В каком месте они должны создаваться, и кем?
Как правило, в простейших случаях с одним презентером, либо используется отдельная фабрика для View, либо сам Презентер/Контроллер является фабрикой для View. Если же мы имеем дело с более сложной конструкцией, опять-таки используется отдельная фабрика для построения триад нижнего уровня. Но это уже несколько выходит за рамки чистого MVP/MVC, здесь надо уже подключать паттерны для выстраивания иерархии приложения — совершенно отдельная тема для разговора
Y> Есть главная форма, предназначенная для отображение групп и контактов, есть еще несколько форм, предназначенных для редактирования/добавления групп и контактов, и, возможно, еще несколько форм для редактирования некоторых свойств группы или контакта. Как в таком случае реализуется архитектура?
В простейшем случае можно выделить один Presenter, который обращается к фабрике View с указанием экземпляр какого интерфейса нужен и работает дальше с ним... Однако при росте приложения это приведет к тому, что презентер будет перегружен совершенно разноплановой логикой и рано или поздно придется выделять отдельные триады, на каждую форму или группу форм (или вообще в самостоятельную триаду MVP может быть выделен каждый контрол). Эти триады могут быть связаны между собой с помощю триад более высокого уровня причем связь может быть осуществлена как строго через презентер, так и через другие элементы триады — смотрите по ссылкам в статье на паттерны HMVC и PAC.
Y> Как я предполагаю, для каждой формы необходимо создание пары Presenter/View, и это создание должно происходить в presenterе главной формы.
Да, это один из вариантов.
Y> И должны ли presenterы знать друг о друге, или же достаточно будет реализовать паттерн с активной моделью, которая сама будет оповещать Views
А как больше нравится.. В своих приложениях я предпочитаю вариант с пассивной моделью и как можно более плоским View, но в конкретной ситуации вполне может оказаться удобнее сделать активную модель.
Поиграйтесь, хоть с тем же справочником, попробуйте разные варианты, посмотрите как удобнее..
Здравствуйте, rsn81, Вы писали:
R>Вопрос по архитектуре... Вы где-то в теме говорили, кажется, что в принципе нужно, чтобы представление могло работать с несколькими моделями.
Не с моделями, а с Презентерами... Работаь View с несколькими моделями — проблематично, в этом случае модели должны соответствовать некоторому контракту, что естественно накладывает на модель определенного рода ограничения.
Да и нужно это не всегда. Вот если у нас View представляет собой контрол, то его переиспользование с несколькими презентерами — одно из основных требований, если же View — достаточно развесистая форма, то переиспользование ее в другой ситуации вряд ли потребуется.
Сама же возможность переиспользования заложена в четком описании контракта для View.
Здравствуйте, <Аноним>, Вы писали:
А>Основное, что не понравилось — дикие тормоза при загрузке/открытии форм, ибо все А>создание объектов происходит через рефлекшн. Особенно если использовать контролы, А>насыщеные графикой (DevExpress в частности) — форма грузится 1.5-2 сек на AthlonXP 1700+ 256Mb RAM
Это не проблемы CAB, это проблемы конкретно DevExpress. Особенно грид там больной. Можешь погонять под профайлером.
Здравствуйте, IB, Вы писали:
IB>Ну как в одном случае связь развернута в одну сторону, в другом — в другую, вот это и есть принципиальнео различие..
Ага, это уже почуял.
IB>Непонятно с какой конкретной реализацией Представления работает Перзентер или непонятно как Презентер работает с несколькими представлениями? И что именно непонятно?
Прочитав ответы ниже, все понял.
IB>Просто развернуть связь в обратную сторону. Презентер имеет прямую ссылку на все активные представления, и является подписчиком на события в этих представлениях возникающие.
Понято, просто мне хочется понять, уступает ли мое представление картины в чем-то вашему или нет.
IB>На накладные расходы при перерисовке он указывает совершенно не справедливо, но даже если и так то, во-первых, как часто вам приходится писать графические редакторы и прочие Представления критичные именно к скорости отображения? А во-вторых, ничто не мешает передать критичный к скорости отображения объект целиком.
Да, можно считать это просто придиркой, в целом это копейки. Разумеется, видеоадаптер не стоит проектировать на основе MVC, а выводить напрямую — для всего свое назначение.
IB>От того что связ развернута в другую сторону. В этом случае вообще получается, что View меняет модель, Presenter — практически Pass-thru объект, который транслирует вызовы View в изменение модели, после чего через событие-же дает View на отрисовку.
Транслирование вызовов View в изменение модели — это Command, по сути тоже обобщенный интерфейс. У вас в этом месте Observer с событиями, в этом и "развертывание в другую сторону", насколько представляю. Я решил не делать Observer при общении представления с предъявителем, потому что этот шаблон ориентирован на общение "одного с многими" (публикатора с подписчиками), а я не встречал пока необходимости общения одного представления с несколькими предъявителями (моделями), об этом написал выше отдельный вопрос вам. Зато вот общение одного предъявителями с несколькими представлениями, которые отображают одну модель, у меня по Observer. У вас в примере это не продемонстрировано (там одно представление только), но в реалии вы же наверно тоже по Observer оповещаете представления?
Здравствуйте, IB, Вы писали:
IB>Не с моделями, а с Презентерами...
Ага, для меня это уже транзитивно, забываю иногда.
IB> Вот если у нас View представляет собой контрол, то его переиспользование с несколькими презентерами — одно из основных требований
Угу, осталось дождаться вашего ответа на вопрос здесь
Здравствуйте, adontz, Вы писали:
A>Да, когда он выделяется. А когда мы разбиваем один объект на кучу более мелких, потому что "так сказал пророк", получая в результате пролему их взаимодействия, то надо не контекст выделять, а менять дизайн.
Нет. Я взял гипотетическую задачу предложенную тобой, гипотетически помыслил и привел логику получения гипотетического решения на основе представленных тобой данных, и на предположении что количество отображаемых сущностей может изменяться. В свете артефактов предоставленных тобой и данного предположения задача решается данным паттерном как родная. При этом я не учитывал артефакты о которых я не знаю, и соответвенно как сделать данную задачу в жизни или есть лучшие решения точно сказать нельзя.
Проблемы взаимодействия я здесь не вижу. Вижу только ее решение.
1. Модель абсолютно пассивна и плохо представляет для чего ее пользуют. Ее задача предоставить данные. Представления полностью изолированы от модели, и соответвенно любое изменение модели не отражается на рисовалках. Как собственно верно и обратное утверждение.
2. Добавление новой отображаемой сущности упрощается.
2.1 Если сущность должна отображаться уникально, то велика вероятность что она может быть описана уже готовым интерфейсом, как то (координаты, название), (путь), (координаты, иконка). То есть, остается реализовать только класс рисовалку поддерживающий данный интерфейс. Контроллер ведь оперирует только интерфейсом.
2.2 Если есть уже готовая рисовалка но при обработке информации есть изменения, то наша задача ограничется только созданием нового контроллера.
3. Достаточно легко строить новые формы на основе уже существующих кирпичей.
4. Система тестируема. Мы не можем автоматизировано построить проверку как работают контроллеры. И мы можем раздельно проверить как рисуются рисовалки.
A>А тут не будет повторяющегося кода Карта рисуется OpenGL, список городов это ListView.
Oops. Только что это был DirectX. Хотя это однокомпозиционно, поскольку вывод зависит только от рисовалок. Можно сделать рисовалки, которые рисуют в DirectX, OpenGL, в формы или в log в виде тупого текста. Ни модель, ни контроллеры от этого практически не меняются. (хотя в контроллерах я допускаю что возможна некоторая несущественная зависимость.) И контекст вывода является пререгативой рисовалок а не контроллеров. Посему возможно контроллерам о нем и знать то не надо.
A>+1. MVC тоже навязывает абстрактные сущности Controller и View, которые очень просто объединить в Control.
Но тогда это уже не будет MVC.
Здравствуйте, adontz, Вы писали:
A>Но почему этот класс не может делегировать рисование одному классу (кстати уже так и есть, поглядите классы *Renderer)
Здравствуйте, IB, Вы писали:
A>>Такс, вот ты и попался великий теоритек. Реализацию в студию. И желательно без прыжков в сторону. IB>Ром, прыжками в сторону занимаешься исключительно ты — половину проигнорировал, все претензии свелись к "эффективности". Ну ей богу, если бы ты просто спрашивал, а не наезжал, то и глупостей меньше наговорил бы, и разобрались бы существенно быстрее.
То есть пример ты привести не можешь. Так и запишем.
IB>Вот скажи мне, великий практик, что мешает Представлению, пользуясь явным контрактом IView сообщить Презентеру, какая именно порция данных нужна ему в данный момент?
Теоретически ничего не мешает. Просто раньше этого не надо было делать, а следовательно налицо усложнение программы на пустом месте. Оно мне не надо.
Здравствуйте, rsn81, Вы писали:
R> У вас в примере это не продемонстрировано (там одно представление только), но в реалии вы же наверно тоже по Observer оповещаете представления?
Зачем? У Презентера есть прямая ссылка на все активные Представления, Observer здесь просто не нужен, а вот View оповещает о происходящих в нем изменениях Презентер именно через Observer.
Здравствуйте, IB, Вы писали:
IB>Зачем? У Презентера есть прямая ссылка на все активные Представления, Observer здесь просто не нужен, а вот View оповещает о происходящих в нем изменениях Презентер именно через Observer.
Все, дошло.
Понял ваше видение, но все же пойду другим путем, который описывал выше.
Здравствуйте, adontz, Вы писали:
A>То есть пример ты привести не можешь.
Я описал как это выглядит, что, тебе по прежнему что-то непонятно? Я не злопамятный, могу объяснить — ты только спрашивай..
A>Теоретически ничего не мешает.
Значит возражение снимается и никакой мифической связности больше нет? Отлично.
A>Просто раньше этого не надо было делать
Надо. Раньше эта логика была во View, теперь в презентере, ее в любом случае надо реализовывать.
A>, а следовательно налицо усложнение программы на пустом месте.
Надо признать, что палец из которого ты высасываешь претензии к паттерну изрядно поистощился.. Может хватит?
A>Оно мне не надо.
Байта ради, я не настаиваю..
Здравствуйте, IB, Вы писали:
IB>Здравствуйте, adontz, Вы писали:
A>>То есть пример ты привести не можешь. IB>Я описал как это выглядит, что, тебе по прежнему что-то непонятно? Я не злопамятный, могу объяснить — ты только спрашивай..
То есть пример ты привести не можешь. Так и запишем — теоретик.
Здравствуйте, adontz, Вы писали:
A>То есть пример ты привести не можешь.
Могу, только не вижу смысла или тебе все-таки что-то непонятно? Или это все к чему ты в итоге можешь придраться?
Эх, слабоват нонче критик пошел.. =)
A> Так и запишем — теоретик.
Да записывай как угодно, не тебе меня критиковать.. Тебя-то уже давно записали..
Здравствуйте, adontz, Вы писали:
A>Более того, я просто хотел чтобы ты пытаясь это сделать, понял что это невозможно по независящим от тебя причинам.
Опять путаешься и сам себе противоречишь?
Теоретически ничего не мешает.
(c) Рома.
Так что же это за независящие причины такие — ничто не мешает, но сделать не дает? Ты можешь их внятно сформулировать или так и будешь балобольством заниматься?
Здравствуйте, IB, Вы писали:
IB>Здравствуйте, adontz, Вы писали:
A>>Более того, я просто хотел чтобы ты пытаясь это сделать, понял что это невозможно по независящим от тебя причинам. IB>Опять путаешься и сам себе противоречишь? IB>
IB>Теоретически ничего не мешает.
Я так про совсем другое говорил. Нечего выдёргивать фразы из контекста.
IB>Так что же это за независящие причины такие — ничто не мешает, но сделать не дает? Ты можешь их внятно сформулировать или так и будешь балобольством заниматься?
А зачем? На слово ты мне не веришь. Пойди набей персональную шишку, тогда и поговорим. Если не через сообразительность, так хоть через старание поумнеешь. Кстати напомню задачу, есть ListViewControl в котором 100 млн записей. Записи хранятся в БД. Предлагается организовать из отображение отожрав 20-30Мб (Нк 50, совесть тоже надо иметь) ОЗУ. Ы? И чтоб объязательно MVP, а иначе не круто. Да, про сортировку не забудь.
Здравствуйте, adontz, Вы писали:
A>А зачем? На слово ты мне не веришь. Пойди набей персональную шишку, тогда и поговорим. Если не через сообразительность, так хоть через старание поумнеешь. Кстати напомню задачу, есть ListViewControl в котором 100 млн записей. Записи хранятся в БД. Предлагается организовать из отображение отожрав 20-30Мб (Нк 50, совесть тоже надо иметь) ОЗУ. Ы? И чтоб объязательно MVP, а иначе не круто. Да, про сортировку не забудь.
Lazy List/Table/Tree — и нет проблем, причем это, скажем так, совсем не пересекается с подходом MVC/MVP.
Здравствуйте, adontz, Вы писали:
A>Я так про совсем другое говорил.
Именно про это, не уворачивайся, все ходы записаны..
A>А зачем? На слово ты мне не веришь.
Я? Верю, конечно, при условии, что ты в состоянии все внятно объяснить.
A> Пойди набей персональную шишку, тогда и поговорим. Золотые слова.
Давай не будем меряться персонально набитыми шишками, а то как в том анекдоте про слона получится..
A> Предлагается организовать из отображение отожрав 20-30Мб (Нк 50, совесть тоже надо иметь) ОЗУ. Ы? И чтоб объязательно MVP, а иначе не круто. Да, про сортировку не забудь.
Так ты не в состоянии сформулировать в чем здесь может быть проблема у MVP? =)
Хинт: посмотри как реализован Virtual Mode в стандартном вин-фрмовском ListView и приведи хоть одну причину, почему точно так же нельзя вынести всю логику в презентер. Если не сможешь — перестань морочить людям голову.
Презентер ничего не знает о представлении кроме интерфейса. Ну что ты придирки из пальца выжимаешь, заняться нечем? 
Мы уже победили, просто это еще не так заметно...
Золотые слова. 