Здравствуйте, adontz, Вы писали:
A>Дело не в том, что это усложнит View.
Именно в этом, если ты все-таки читал стаью..
A> Дело в том, что при наличии 5-6 компонент всех вариаций методов ты просто не напишешь.
А зачем мне писать все?
A>Так уж и неправданному?
Именно.
A> ООД должен ускоряя разработку программы не слишком тормозить исполнение.
Как ты думаешь, на сколько это затормозит?
A> И уж точно не стоит передавать туда новые пути.
Ну так и не передавай, в чем проблема-то?
Я правильно понял, что все твои претензии свелись к тому, что это будет якобы не эффективно?
Здравствуйте, IB, Вы писали:
A>>Он обобщённый потому что интерфейс который реализуют все виды. IB>Да не все, а только те, которые работают с определенным набором данных. Презентер вполне может работать с несколькими IView для разных данных и с моделью могут иметь дело несколько презентеров для разных задачь...
Получается логику View перетащили в Presenter. Типа понизили связность, да?
A>>Например считывать из модели по мере необходимости. IB>И что тебе мешает делать то же самое в MVP?
То что данные View не считываются, они туда запихиваются извне.
A>>View изменился?! Мда, приехали. Я такой бред никогда не нёс. IB>Так у тебя и View еще никогда не меняется? А данные ты как редактируешь?
View не меняется сам по себе. Только при изменении модели.
A>>Затем что ты не знаешь заранее какие данные нужны конкретному View. IB>Почему?
Потому что у тебя только интерфейс IView. Ах ну да, у тебя теперь IView1, IView2, IView3.
A>> С чего это тебе именно сегодня вдруг стал непонятен термин расширеный синглтон? IB>Да он мне никогда не был понятен
Вот! Вот ты и проговорился
IB>>>Могу я глядя на метод, но не зная ее реализации, утверждать, что это вот одна "точку доступа", а здесь вот у нас их на самом деле несколько? A>>Нет, не можешь. IB>И ты здесь никакого косяка не видишь? Все нормально?
Дял меня — да.
IB>То есть все-таки экземпляров, а не точек доступа?
Здравствуйте, adontz, Вы писали:
A>Так уж и неправданному? ООД должен ускоряя разработку программы не слишком тормозить исполнение.
A>Например у меня есть модель — географически даные. MapView рисует карту (Bitmap), а на ней города (List<Town>) и пути по которым двигались автомобили и есть TownsView который выводит в столбик список городов. Если изменились пути движения автомобилей, то TownsView на это глубоко наплевать. И уж точно не стоит передавать туда новые пути.
Ты пристал к IView как универсальному интерфейсу который должен решить все твои проблемы, и дал ему очень сложную задачу. Так не бывает. Если с TownsView все понятно, то как MapView так и контроллеры к нему выразить в одном классе не удастся. Тут присутсвует библиотека классов. как со стороны вьюв, так и со стороны контроллеров. Вполне понятно почему нельзя делать все в одной форме. Ты потеряешь композиционность. Если ты вделаешь сразу и рисование битмапа, обработку координат и рисование машин, рисование путей — то это будет монстр похожий на мусорку. А если еще обяжут рисовать только автобусы, или только трамваи и именно в виде трамвая? Поэтому декомпозируем по тому что именно нам нужно отобразить. Это будет рисование карты, рисование пути, рисование обычной машины и рисование допустим трамвая. Рисование машины и трамвая можно было бы совместить, так как отличаются только иконкой. Но тут встает вопрос, что для трамвая нужны рельсы, а это не совсем обычный путь. Поэтому разделяем на функции обработки где нужно рисовать, и как рисовать. То есть контроллер и вьюв. Соответвсенно, где рисовать решает некоторый набор классов контроллеров который зависит от того, что мы рисуем. И что удивительно, связь между контроллерами и классами рисования можно описать элементарными интерфейсами. Допустим. Для путей (как простого для машин, так и для электричества с рельсами для трамваев) важны массив точек для интраполяции. Допустим они наследуются от IArrayPointsPainter. Для машин и трамваев важна иконка и месторасположение — ICarPointPainter. Для городов месторасположение и название ICityPainter. Для самой картинки IBitmapPainter. При этом ICityPainter нужен не только в MapView, но и TownsView. По этим интерфейсам можно работать, и самое главное, если будут введены тролейбусы — то отрисовать их можно будет с уже текущими интерфейсами, и даже типами. Другой вопрос, что с тролейбусами может быть связана несколько другая логика(так как нужны лепектрические провода). А если у нас изменились города, то вполне достаточно воспользоваться обновить только доступные интерфейсы ICityPainter. Все — рисовальщики не знают о модели, о ней знают только контроллеры. Контракты достаточно сложного решения расписаны.
Здравствуйте, GlebZ, Вы писали:
GZ>Контракты достаточно сложного решения расписаны.
Расписно конечно классно, но ни в OpenGL, ни в DirectX, ни даже в GDI это рисование не очень-то укладывается. Композитность конечно штука неплохая, и CompositeView объединяющий несколько View в данной задаче может быть пригодился бы, но в тоже время должен быть глобальный View — владелец IDirect3DDevice, hRenderingContext, PAINTSTRUCT или чего там надо. Вобщем некоторый контекст рисования в котором надо всё раз отрисовать. На карте я не могу отдельно перерисовать города, я вынужден перерисовать всё сразу. И кстати дорисовывать в несколько циклов рисования я тоже не могу. А у списка городов не так. И эти особенности IViewMap, IViewTowns, IViewSomethingElse о которых приходится знать презентеру, потому что теперь уже ему надо хранить этот контекст и передавать его разным IView. Либо создавать ещё какого-то отдельного RenderingContextManager. Я бы не назвал это самым удачным употреблением Flyweight.
Гораздо лучше, когда IViewTowns подписывается на Towns.Changed, а IViewMap и на Towns.Changes и на Tracks.Changed и они сами решают на что подписыватся, что считывть, как и когда перерисовывать и т.д. Меньше сущностей, проще контроль.
Здравствуйте, adontz, Вы писали:
A>Получается логику View перетащили в Presenter.
Именно! Дошло наконец..
A>Типа понизили связность, да?
Не типа, а понизили, только это другой вопрос, не пытайся все опять в кучу смешать..
Связность мы понизили с помощю паттерна IoC, что никак не связано с переносом логики из View в Presenter.
A>То что данные View не считываются, они туда запихиваются извне.
И чем это мешает запихивать данные во View по мере необходимости?
A>View не меняется сам по себе. Только при изменении модели.
Еще раз. Как ты собираешься узнавать о том, что пользователь отредактировал данные во view?
A>Потому что у тебя только интерфейс IView.
И? Почему это я не знаю какие данные нужны этому интерфейсу?
A>Вот! Вот ты и проговорился
Разьве? Я никогда и не скрывал, что мне непонятны твои термины, уж слишком они отличаются от общепринятых..
IB>>И ты здесь никакого косяка не видишь? Все нормально? A>Дял меня — да.
Тогда пожалуйста, не пытайся трактовать хорошо известные паттерны, тем более с такими новаторскими идеями — не оценят...
По крайней мере, до тех пор пока не подгонишь свою систему терминов к общепринятой.. )
Здравствуйте, adontz, Вы писали:
A>Расписно конечно классно, но ни в OpenGL, ни в DirectX, ни даже в GDI это рисование не очень-то укладывается. Композитность конечно штука неплохая, и CompositeView объединяющий несколько View в данной задаче может быть пригодился бы, но в тоже время должен быть глобальный View — владелец IDirect3DDevice, hRenderingContext, PAINTSTRUCT или чего там надо. Вобщем некоторый контекст рисования в котором надо всё раз отрисовать. На карте я не могу отдельно перерисовать города, я вынужден перерисовать всё сразу. И кстати дорисовывать в несколько циклов рисования я тоже не могу. А у списка городов не так. И эти особенности IViewMap, IViewTowns, IViewSomethingElse о которых приходится знать презентеру, потому что теперь уже ему надо хранить этот контекст и передавать его разным IView. Либо создавать ещё какого-то отдельного RenderingContextManager. Я бы не назвал это самым удачным употреблением Flyweight.
И что тебе здесь не нравится? Выделения контекста вещь полезная. Поскольку в ней можно держать достаточно много простых хелперных функций. Например определения принадлежности координат региону. A>Гораздо лучше, когда IViewTowns подписывается на Towns.Changed, а IViewMap и на Towns.Changes и на Tracks.Changed и они сами решают на что подписыватся, что считывть, как и когда перерисовывать и т.д. Меньше сущностей, проще контроль.
Не всегда это есть верно. Даже скажу больше, чаще не верно. Чем меньше повторного кода, тем лучше контроль. Для уменьшения повторного кода нужна декомпозиция. А поскольку существует(а чаще всего неоправданная) боязнь сущностей, то так и появляется мусорка кода которую рефакторить принципиально невозмножно (как и определить чем эта мусорка в тот или иной момент занимается). Каждая программная сущность должна выполнять строго определенную задачу. И если четко выполнять данное предписание, то при рефакторинга ты получишь и MCV/MCP и другие паттерны. Но самое главное применение того или иного паттерна будет всегда оправданным.
Здравствуйте, IB, Вы писали:
A>>Получается логику View перетащили в Presenter. IB>Именно! Дошло наконец..
Что значит дошло? Это-то понятно, просто мне это очень не нравится
IB>Связность мы понизили с помощю паттерна IoC, что никак не связано с переносом логики из View в Presenter.
Связность это не только Type Declaration References. Теперь Presenter знает о View многие интимные подробности, которые никак не описываются через интерфейс IView.
A>>То что данные View не считываются, они туда запихиваются извне. IB>И чем это мешает запихивать данные во View по мере необходимости?
Тем что View могут быть некоторые данные просто не нужны. Типичный случай — Virtual List View. Там данные могут вообще динамически подгружатся из БД, кешироватся и проч. Presenter это просто не потянет, это задача Model и View.
A>>View не меняется сам по себе. Только при изменении модели. IB>Еще раз. Как ты собираешься узнавать о том, что пользователь отредактировал данные во view?
Иван, неужели тебе не известно, что данные во View не редактируются?! Нельзя так смешить, совсем нельзя.
Вот цепочка вызов для EditBox
EditBoxControl.OnKeyDown->EditBoxController.OnKeyDown->EditBoxModel.InsertChar->EditBoxModel.ValueChanged->EditBoxView.OnValueChanged->EditBoxControl.Refresh()
A>>Потому что у тебя только интерфейс IView. IB>И? Почему это я не знаю какие данные нужны этому интерфейсу?
Потому что он обобщённый Удивительно как ты умудряешься непонимать простейшие вещи. Возьмём Virtual ListView. Он может хранить до миллиарда строк. Такой объём данных в памяти просто не поместится. Куда правильнее, да чего уж там, единственный возможный вариант, это когда ListView запрашивает часть данных необходимых для визуализации. причём никто кроме ListView не знает какая именно частть нужна. Эту логику в какой-то внешний Presenter ты просто не вынесешь.
IB>>>И ты здесь никакого косяка не видишь? Все нормально? A>>Дял меня — да. IB>Тогда пожалуйста, не пытайся трактовать хорошо известные паттерны, тем более с такими новаторскими идеями — не оценят... IB>По крайней мере, до тех пор пока не подгонишь свою систему терминов к общепринятой.. )
У тебя просто проблемы с воображением. Наверное, тебя тебя поражает, что точка пересечений ножей гильотины может двигатся быстрее скорости света, да и другие нематериальные абстракции.
Здравствуйте, GlebZ, Вы писали:
GZ>И что тебе здесь не нравится? Выделения контекста вещь полезная.
Да, когда он выделяется. А когда мы разбиваем один объект на кучу более мелких, потому что "так сказал пророк", получая в результате пролему их взаимодействия, то надо не контекст выделять, а менять дизайн.
A>>Гораздо лучше, когда IViewTowns подписывается на Towns.Changed, а IViewMap и на Towns.Changes и на Tracks.Changed и они сами решают на что подписыватся, что считывть, как и когда перерисовывать и т.д. Меньше сущностей, проще контроль.
GZ>Не всегда это есть верно. Даже скажу больше, чаще не верно. Чем меньше повторного кода, тем лучше контроль.
А тут не будет повторяющегося кода Карта рисуется OpenGL, список городов это ListView.
GZ>Для уменьшения повторного кода нужна декомпозиция.
Я бы сказал "удачная декомпозиция"
GZ>А поскольку существует (а чаще всего неоправданная) боязнь сущностей, то так и появляется мусорка кода которую рефакторить принципиально невозмножно (как и определить чем эта мусорка в тот или иной момент занимается). Каждая программная сущность должна выполнять строго определенную задачу. И если четко выполнять данное предписание, то при рефакторинга ты получишь и MCV/MCP и другие паттерны. Но самое главное применение того или иного паттерна будет всегда оправданным.
+1. MVC тоже навязывает абстрактные сущности Controller и View, которые очень просто объединить в Control.
Здравствуйте, adontz, Вы писали:
A> Это-то понятно, просто мне это очень не нравится
Твое право.. Почему сделано именно так — я описал.
A> Теперь Presenter знает о View многие интимные подробности, которые никак не описываются через интерфейс IView.
Каким образом и с чего ты это взял? Опять не разобрамшись критиковать лезешь?
Presenter по определению не может ничего знать о View кроме интерфейса, именно для этого интерфейс и вводится, чтобы Presenter не знал никаких подробностей о View.
Ты не учишься, даже когда тебе ссылки под нос подкладывают.
A>Тем что View могут быть некоторые данные просто не нужны.
Ну и? Если не нужны, значит они туда не будут поставляться, в чем проблема-то?
A> Presenter это просто не потянет, это задача Model и View.
Presenter это тянет в лучшем виде, не фантазируй..
A>Иван, неужели тебе не известно, что данные во View не редактируются?!
Ну расскажи мне, как называется то место, где пользователь вводит данные
A> Нельзя так смешить, совсем нельзя. Вот цепочка вызов для EditBox
Ты прав..
Если кто-то не в состоянии абстрагироваться от конкретной цепочки вызовов, а туда же — в архитекторы лезет, это уже даже не смешно..
A>Потому что он обобщённый
Я тебе уже показал, что это не так.. Если не дошло, можешь перечитать..
A> Удивительно как ты умудряешься непонимать простейшие вещи.
Прости, Ром, но как уже неоднократно можно было убедиться, твоя логика не может быть простой.. Куда уж нам, рядовым архитектам в ней разобраться, если даже ты сам путаешься..
A> причём никто кроме ListView не знает какая именно частть нужна.
С чего ты взял, что никто?
A> Эту логику в какой-то внешний Presenter ты просто не вынесешь.
Она туда великолепно выносится, вот это-то ка краз и должно быть очевидно.
Ром, в последний раз прошу — разберись с паттерном, а не придумывай придирки на ходу. Или задавай вопросы, если что непонятно, я отвечу.
A>У тебя просто проблемы с воображением.
Доктор, а таблеток не дадите? Конечно, если ты не можешь оперировать общепринятыми терминами, разобраться как работает пара не самых сложных на свете паттернов, и внятно объяснить что ты имеешь ввиду, то естественно, в этом виновато мое воображение..
A> Наверное, тебя тебя поражает, что точка пересечений ножей гильотины может двигатся быстрее скорости света, да и другие нематериальные абстракции.
Хех, Ром.. Если бы тебя этот факт не поражал, то ты бы не привел его в качестве примера, догадывашься к чему я клоню?
Здравствуйте, IB, Вы писали:
IB>Presenter по определению не может ничего знать о View кроме интерфейса, именно для этого интерфейс и вводится, чтобы Presenter не знал никаких подробностей о View.
Ещё раз специально для тебя — связность это не только type declaration referencing.
A>>Тем что View могут быть некоторые данные просто не нужны. IB>Ну и? Если не нужны, значит они туда не будут поставляться, в чем проблема-то?
Ну а кто решит, что их туда не надо поставлять? Presenter. А как? На основе той информации, которая IView не описывается, но тем не менее существует и повышает связность.
IB>Если кто-то не в состоянии абстрагироваться от конкретной цепочки вызовов, а туда же — в архитекторы лезет, это уже даже не смешно..
Я как раз в состоянии, я тебе просто разжевал очевидну вешь, чтобы ты не нёс чушь, будто бы View редактируется. Судя по всему зря разжёвывал, не помогло.
IB>Куда уж нам, рядовым архитектам в ней разобраться, если даже ты сам путаешься..
Я путаюсь? У тебя тут View редактируеся, куда уж мне до тебя.
A>> причём никто кроме ListView не знает какая именно частть нужна. IB>С чего ты взял, что никто? A>> Эту логику в какой-то внешний Presenter ты просто не вынесешь. IB>Она туда великолепно выносится, вот это-то ка краз и должно быть очевидно.
Такс, вот ты и попался великий теоритек. Реализацию в студию. И желательно без прыжков в сторону.
Прочитал статью, очень понравилась. После прочтения сразу захотелось переписать существующее приложение, благо есть время и желание. Но после просмотра примера, который идет со статьей, возник вопрос. Как происходит взаимодействие, если у нас несколько пар presenter/view? В каком месте они должны создаваться, и кем? Для примера, возмем простое приложение, реализующее функции адресной книги. Есть главная форма, предназначенная для отображение групп и контактов, есть еще несколько форм, предназначенных для редактирования/добавления групп и контактов, и, возможно, еще несколько форм для редактирования некоторых свойств группы или контакта. Как в таком случае реализуется архитектура? Как я предполагаю, для каждой формы необходимо создание пары Presenter/View, и это создание должно происходить в presenterе главной формы. Еще в форуме было предложено для этой цели использовать Factory. И должны ли presenterы знать друг о друге, или же достаточно будет реализовать паттерн с активной моделью, которая сама будет оповещать Views
Заранее спасибо за помощь в разъяснении данного вопроса.
Здравствуйте, adontz, Вы писали:
A>Не будет. представление в процессе самостоятельного считывания данных может себя не перерисовывать.
Почему вы решили, что MVP обязывает представление перерисовываться без какой-либо самостоятельной логики? Если так в примере автора, то это же еще ни о чем не говорит: указали направление, а конкретика реализации — ваше творчество.
Здравствуйте, IB, Вы писали:
IB>Угу. Именно поэтому вводится обобщенный интерфейс для Представления и для вывода информации в нужном виде достаточно всего лишь реализовать этот интерфейс. В зависимости от ситуации Презентер имеет дело с конкретной реализацией этого интерфейса, но с какой именно ему совершенно все равно.
Наверно не очень подробно описал. Принципиального различия в работе предъявителя с представлениями нет: у вас предъявитель работает с интерфейсом IView, а в моем варианте в рамках шаблона проектирования Observer, к примеру, с интерфейсом ISubscriber, то есть интерфейсом подписки представления на события предъявителя — особенной разницы нет.
Просто в вашем примере не очень понятно, как несколько представлений будут работать с одной моделью-предъявителем, а как иначе, нежели как через Observer, где предъявитель является публикатором? Хотя вру... вы, кажется, писали, что в рамках MVP можно оставить активную модель, то несколько представлений подпишутся, как и в MVC, на события одной модели. Но ведь это сложнее: усложняется модель и представление — нежели сделать предъявитель публикатором.
IB>Это плохо тем, что во-первых, вносит лишнюю логику в Пердставление. По сути логика работы с данными размазывается между Представлением и Презентером, в то время как основная цель паттерна сделать Представление как можно проще и по возможности сосредоточить всю логику отображения в презентере. IB>В третих, это здорово уменьшает шанс повторного использования того же Представления с другим Презентером.
С другой стороны, как работает представление с предъявителем... Это опять же интерфейс по шаблону проектирования Command, к примеру, ICommand. То есть представление тоже не сильно связано с предъявителем — оно может быть спокойно перекинуто на другой предъявитель, который реализует интерфейс Command.
Согласен, что часть логики все же переходит в представление. Но... здесь я соглашусь с adontz, который справедливо указывает на накладные расходы при прорисовке графических форм представлений, если последние полностью лишены логики перерисовки. Мне все же удобнее оставить представление чуточку "умным", понимаю, что тестирование его при этом усложнится.
IB>Во-вторых, появляется лишний раунд трип при обновлении Представления — сначала в Представление отсылается событие, а потом оно лезет обновляться.
Отчего? Почти как и у вас: в событии предъявитель шлет представлению данные для обновления — представление абсолютно ничего не знает о модели, не знает, где ее искать, все только через предъявитель.
IB>Ведь не случайно, даже в классическом шаблоне именно контроллер знает о представлении, но не наоборот.
Вот и не пойму, как в классике предполагается работа нескольких представлений с одной моделью.
Здравствуйте, ybouts, Вы писали:
Y> Как я предполагаю, для каждой формы необходимо создание пары Presenter/View, и это создание должно происходить в presenterе главной формы.
Представление для каждой формы — возможно, а вот предъявитель, как понимаю, ни в коем случае, потому что форма, а значит представление должно уметь работать с несколькими предъявителями, чтобы отображать одну и ту же модель — это постоянно встающая задача графических приложений.
Y> Еще в форуме было предложено для этой цели использовать Factory.
Возможно вы забыли...
Я не предлагал фабрикой создавать пары предъявитель-представление, а только предъявители. Представление может инициализировать, в принципе, и сама форма. Возможно есть такие задача, но сам не сталкивался, когда необходимо, чтобы несколько форм отображали одно и то же представление — то есть фабрики представлений вроде бы как и не нужно.
Y> И должны ли presenterы знать друг о друге, или же достаточно будет реализовать паттерн с активной моделью, которая сама будет оповещать Views Здесь
Здравствуйте, rsn81, Вы писали:
Y>> Еще в форуме было предложено для этой цели использовать Factory. R>Возможно вы забыли... R>Я не предлагал фабрикой создавать пары предъявитель-представление, а только предъявители. Представление может инициализировать, в принципе, и сама форма. Возможно есть такие задача, но сам не сталкивался, когда необходимо, чтобы несколько форм отображали одно и то же представление — то есть фабрики представлений вроде бы как и не нужно.
Спасибо, что разьяснили, я и вправду не до конца понял, поэтому и спрашиваю.
Здравствуйте, adontz, Вы писали:
A>Здравствуйте, Аноним, Вы писали:
>>>Model-View-Controller в .Net А>>А кто что скажет про DataBinding? Чем не контроллер...
A>Очень интересно с какой точки зрения это так выглядит Можно по-подробнее?
Хм не совсем контроллер больше на презентера похож
задача презентера связать данные от моджели с видом и далее от вида передать данные в
модель, по моему датабиндинг с этим вполне себе справляется. или же я что то не учел?
Вопрос по архитектуре... Вы где-то в теме говорили, кажется, что в принципе нужно, чтобы представление могло работать с несколькими моделями.
Варианты:
1. Как всегда делал. Такое представление просто будет композитом, состоящим из нескольких представлений, каждое из которых работает со своей моделью, в рамках концепции MVP — со своим предъявителем. Это не исключает возможность работы нескольких представлений с одним предъявителем. Итого: связка "много представлений — один предъявитель".
2. Сделать иначе. То есть будет сложная связка "много представлений — много предъявителей", и в ту и в другую сторону идут оповещения по шаблону проектирования Observer:
— связка "один предъявитель — много представлений": предъявитель оповещает все представления пописавшиеся на события об изменении модели, то есть какое-то представление скомандовало изменить модель, а другие представления также получили оповещение после изменения модели;
— связка "одно представление — много предъявителей": представление может оповещать (командовать на изменение модели) всем предъявителям, которые принудительно были самим представлением подписаны на прием от него команд.
Мне вот все кажется, что вариант 2 сложный. Зачем городить архитектурное решение там, где можно все решить обычным наследованием и инкапсуляцией (вариант 1). Может я что-то не учел?
Здравствуйте, rsn81, Вы писали:
R> Принципиального различия в работе предъявителя с представлениями нет:
Ну как в одном случае связь развернута в одну сторону, в другом — в другую, вот это и есть принципиальнео различие..
R>Просто в вашем примере не очень понятно, как несколько представлений будут работать с одной моделью-предъявителем,
Непонятно с какой конкретной реализацией Представления работает Перзентер или непонятно как Презентер работает с несколькими представлениями? И что именно непонятно?
R> а как иначе, нежели как через Observer, где предъявитель является публикатором?
Просто развернуть связь в обратную сторону. Презентер имеет прямую ссылку на все активные представления, и является подписчиком на события в этих представлениях возникающие.
R> Но... здесь я соглашусь с adontz, который справедливо указывает на накладные расходы при прорисовке графических форм представлений, если последние полностью лишены логики перерисовки.
На накладные расходы при перерисовке он указывает совершенно не справедливо, но даже если и так то, во-первых, как часто вам приходится писать графические редакторы и прочие Представления критичные именно к скорости отображения? А во-вторых, ничто не мешает передать критичный к скорости отображения объект целиком.
R> Мне все же удобнее оставить представление чуточку "умным", понимаю, что тестирование его при этом усложнится.
Это на усмотрение.. В каждом конкретном случае гранулярность отображаемых данных оперделяется исходя из задачи.
R>Отчего?
От того что связ развернута в другую сторону. В этом случае вообще получается, что View меняет модель, Presenter — практически Pass-thru объект, который транслирует вызовы View в изменение модели, после чего через событие-же дает View на отрисовку.
R>Вот и не пойму, как в классике предполагается работа нескольких представлений с одной моделью.
А что непонятного? Презентер является фабрикой для View и имеет ссылки на все активные Представления. Как только в представлении происходит событие, Презентер соответствующим образом изменяет модель и дает нужным представлениям команду на перерисовку.
Мы уже победили, просто это еще не так заметно...
