В целом MVC и Document-View, как его логическое продолжение вполне
A>>Дальше читать как-то сразу расхотелось. J>Почему?
Ну наверное потому что Document-View это не логическое продолжение Model-View-Controller, а примитивизация.
Кстати сокрушательства автора, о том как сложно реализовать MVC в .Net меня что-то не очень убедили. Да, действительно в WinAPI отрисовка элемента управления и его реакция на внешний мир реализуются в одной функции WndProc, а в Windows.Forms как результат, в одном, унаследованном от Control, классе. Но почему этот класс не может делегировать рисование одному классу (кстати уже так и есть, поглядите классы *Renderer), а реакцию на внешний мир другому я не монимаю. Вернее не понимаю, почему
код, который порождают среды и библиотеки провоцирует интегрировать Контроллер в Представление.
Если уж на то пошло, провоцирует не генерируемый код, а WinAPI. И не так уж и провоцирует. Тот кому это надо, Controller от View отделит без проблем. Но что самое существенное, почему это всё вдруг попало в раздел "Недостатки MVC и Document-View"?! С какой радости особенности реализации Windows.Forms вдруг стали недостатками MVC?
И, главное, что такое MVP? Это какой-то очень странный паттерн резко повышающий связность, потому что теперь практический у всех есть ссылки на всех. Об этом знает и сам автор
Однако здесь, в отличие от случая с Моделью, создание конкретного экземпляра конкретного класса Представления, может обернуться большими неудобствами. При наличии тесной связи между Presenter-ом и Представлением будет сложно реализовать замену Представлений и использование нескольких Представлений для одного Presenter-а, к тому же, это затруднит независимое тестирование Presenter-а
Взамен, в качестве костыля, нам предлагают у всех View реализовать некоторый интерфейс IView. Это уменьшило связность? Ничуть! Посмотрите на интерфейс — он практически дублирует модель. В принципе и раньше представление знало о модели, но раньше эти знания не навязывались. Представление вполне могло интересоватся лишь частью модели. Кроме того, то что модель теперь не медиатор влечёт и другие, куда более существенные недостатки.
Во-первых, раньше модель могла расслытать оповещения только когда действительно что-то изменилось, потому что ей-то уж виднее совпадает старое значение с новым или нет. Теперь это не так.
Во-вторых, модель могла расслать оповещения об изменении группы свойств. То есть, например, не XChanged, YChanged, а PositionChanged, а View в свою очередь считывать свойства группами. Теперь же нельзя по отдельности вызывать SetX, SetY. Это во многих случаях повлечёт неадекватное поведение View, когда часть свойств имеют старые значения, а часть новые. Приходится делать транзакции в виде операторных скобок BeginUpdate/EndUpdate.
Вобщем то, что тов. Бодягин представляет как последнее достижение программистской мысли, на мой взгляд просто пример неудачного дизайна. Я вообще уже успел заметить что некоторые паттерны проектирования он склонен воспринимать крайне оригинально.
Здравствуйте, adontz, Вы писали:
A>Ну наверное потому что Document-View это не логическое продолжение Model-View-Controller, а примитивизация.
Можешь на пальцах объяснить, почему примитивизация не может быть логическим продолжением?
A>Кстати сокрушательства автора, о том как сложно реализовать MVC в .Net меня что-то не очень убедили.
Видно, что дальше ты действительно не читал, ну а если не читал, зачем тогда критиковать? В смешное положение себя ставишь.. )
A> Вернее не понимаю, почему
код, который порождают среды и библиотеки провоцирует интегрировать Контроллер в Представление.
А ты подумай..
A> С какой радости особенности реализации Windows.Forms вдруг стали недостатками MVC?
Сам же написал, не Windows.Forms, а WinAPI... =)
Ром, если уж берешься критиковать, то во-первых, дочитывай все-таки до конца и внимательно, а во-вторых, будь последователен.
А то твое желание задеть явно превышает возможности.. )
A>И, главное, что такое MVP? Это какой-то очень странный паттерн резко повышающий связность, потому что теперь практический у всех есть ссылки на всех.
Роооом, я тебя очень прошу. Давай, впредь, прежде чем критиковать ты сначала разберешься в вопросе, хорошо? А-то совсем как-то некрасиво получается, тебе приходится азы растолковывать. Причем ладно бы ты просто учился, а то ведь агрессивно упорствуешь.. =)
A>Взамен, в качестве костыля, нам предлагают у всех View реализовать некоторый интерфейс IView. Это уменьшило связность? Ничуть!
Рома, ну не смеши.. Ну право-слово, твое желание найти у меня ошибки лишь демонстрирует твое .... эээ.. слабое знание предмета )
Во-первых, прежде чем разбираться с высокоуровневыми паттернами типа MVC/MVP, разберись с основами, почитай про архитектурный принцип Inversion of Control (у Фаулера он описан в виде паттерна Dependency Injection), и про вопросы связности системы, которые он решает. Для справки, на основе ровно этого принципа построена Java-вская визуальная библиотека Swing (что характерно тот самый MVC), которая по праву считается одной из лучших в архитектурном плане.. Хочешь сказать у ребят тоже проблемы с дизайном?
А во-вторых, опять-таки для справки, практически во всех вариантах MVC, включая оригинальный смолтолковский, View обладает well-known интерфейсом и все взаимодействие view и остальных частей системы происходит именно через этот интерфейс (как у меня и описано). Это не особенность MVP это практически основа паттерна MVC — тот принцип на котором он построен. И в статье, я объяснил, почему сделано именно так, но ты же дальше второго раздела не читал..
A> Посмотрите на интерфейс — он практически дублирует модель. В принципе и раньше представление знало о модели, но раньше эти знания не навязывались. Представление вполне могло интересоватся лишь частью модели.
Ну уж тот факт, что в данном случае интерфейс похож на модель лишь в силу примитивизма примера должен быть очевиден даже для тебя.. Ром, не пытайся казаться менее сообразительным.. ) Надеюсь тебе не надо объяснять, что интерфейс декларирует лишь то что надо для работы данного типа представлений, а вовсе не всю модель?
A>Кроме того, то что модель теперь не медиатор влечёт и другие, куда более существенные недостатки. A>Во-первых, раньше модель могла расслытать оповещения только когда действительно что-то изменилось, потому что ей-то уж виднее совпадает старое значение с новым или нет. Теперь это не так.
Опять невнимательно читал? Чем отдельный медиатор для набора моделей отличается от презентера, который в MVP берет функции медиатора на себя? И каким магическим образом медиатору станет известно о моделях больше, чем сами модели захотят о себе сообщить?
A>Вобщем то, что тов. Бодягин представляет как последнее достижение программистской мысли, на мой взгляд просто пример неудачного дизайна.
Да-да, и Фаулер, тоже хреновый архитектор, между нами говоря, и Component UI App Block (как раз по принципу MVP построен), тоже отстой полный, и только Рома Акопов, знает как правильно дизайнить..
A> Я вообще уже успел заметить что некоторые паттерны проектирования он склонен воспринимать крайне оригинально.
То есть, называть экземпляр — экземпляром, а не "точной входа
" и не уродовать до неузнаваемости паттерн Singleton — это называется "воспринимать крайне оригинально" ?
А тот факт, что MethodName(Int16 i) оказывается 65535 точек входа — вообще можно признать шуткой месяца
Так что молчал бы уж, про оригинальность восприятия...
Здравствуйте, Jericho113, Вы писали:
J>Никак не соображу блин как в подход предлагаемый MVP может вписаться биндинг, т.е. автоматическая J>привязка данных к контролу ...
По разному, вариантов довольно много.
Полярные случаи — если представление работает только с примитивными типами, то в презентере происходит прямая привязка модели или объекта DTO к интерфейсу View, если же представление само умеет работать с DTO, то привязка происходит уже внутри представления, а взаимодействие с презентером происходит на уровне DTO объектов...
Здравствуйте, IB, Вы писали:
A>>Ну наверное потому что Document-View это не логическое продолжение Model-View-Controller, а примитивизация. IB>Можешь на пальцах объяснить, почему примитивизация не может быть логическим продолжением?
Могу (элементарно по хронологии появления), но не хочу скатыватся во флейм.
A>>С какой радости особенности реализации Windows.Forms вдруг стали недостатками MVC? IB>Сам же написал, не Windows.Forms, а WinAPI... =)
Windows.Forms хотя и использует WinAPI, но являясь слишком тонкой обёрткой не изменило ситуацию в корне.
IB>Ром, если уж берешься критиковать, то во-первых, дочитывай все-таки до конца и внимательно, а во-вторых, будь последователен.
Вообще-то я дочитал.
IB>А то твое желание задеть явно превышает возможности.. )
У тебя проблемы, мания преследования, хочешь об этом поговорить?
IB>Во-первых, прежде чем разбираться с высокоуровневыми паттернами типа MVC/MVP, разберись с основами, почитай про архитектурный принцип Inversion of Control (у Фаулера он описан в виде паттерна Dependency Injection), и про вопросы связности системы, которые он решает. Для справки, на основе ровно этого принципа построена Java-вская визуальная библиотека Swing (что характерно тот самый MVC), которая по праву считается одной из лучших в архитектурном плане.. Хочешь сказать у ребят тоже проблемы с дизайном?
У тебя проблемы с логикой, ты чтобы показать что MVP не повышает связность, говоришь что в Swing используется MVC.
IB>А во-вторых, опять-таки для справки, практически во всех вариантах MVC, включая оригинальный смолтолковский, View обладает well-known интерфейсом и все взаимодействие view и остальных частей системы происходит именно через этот интерфейс (как у меня и описано).
А вот это уже просто не правда. View подписывается на события модели, но при этом сам никакого интерфейса не предоставляет. Так что не надо ля-ля. Слабо знание предмета как раз у тебя. И твои "Гы-ы-ы, Рома, ЛОЛ, какой ты тупой" лично на меня никакого впечатления не произвели.
IB>Это не особенность MVP это практически основа паттерна MVC — тот принцип на котором он построен. И в статье, я объяснил, почему сделано именно так, но ты же дальше второго раздела не читал..
Паттерн MVC не требует от View реализации каких бы то ни было интерфейсов. Так что всё дальнейшее так же не верно.
IB> То есть, называть экземпляр — экземпляром, а не "точной входа
" и не уродовать до неузнаваемости паттерн Singleton — это называется "воспринимать крайне оригинально" ? IB> А тот факт, что MethodName(Int16 i) оказывается 65535 точек входа — вообще можно признать шуткой месяца
Это действительно шутка, только твоя. Очередной бред, который мне приписал, так и не поняв смысла сказанного.
IB> Так что молчал бы уж, про оригинальность восприятия...
Последний раз, для тех кто в танке. Точка входа это не метод. Метод с факсированными значениями парметров так же не является точкой входа. Всё чем я могу тебе помочь, так это просто привести пример:
CultureInfo ci1 = CultureInfo.GetCultureInfo(1049);
CultureInfo ci2 = CultureInfo.GetCultureInfo("ru-RU");
bool test = ci1 == ci2; // Бодягин не верит, но тут будет true.
GetCultureInfo(1049) и GetCultureInfo("ru-RU") это одна и та же точка входа, но разные методы с разными параметрами.
Вобщем в хамстве ты разбираешься лучше чем в паттернах. Счастливо оставаться. Мне за твоё обучение никто не платит.
Здравствуйте, adontz, Вы писали:
A>Могу (элементарно по хронологии появления), но не хочу скатыватся во флейм.
А ты не скатывайся, просто посмотри на хронологию.. )
A>Windows.Forms хотя и использует WinAPI, но являясь слишком тонкой обёрткой не изменило ситуацию в корне.
А кто сказал, что должно было изменить? Ром, ты хотя бы себя читай, что ли.. )
A>Вообще-то я дочитал.
Значит плохо дочитал...
A>У тебя проблемы, мания преследования, хочешь об этом поговорить? A>У тебя проблемы с логикой, ты чтобы показать что MVP не повышает связность, говоришь что в Swing используется MVC.
Рома, не ищи проблемы у меня, разберись сначала со своими..
Например, с внимательным чтением — чтобы показать, что MVP не повышает связность, я говорю, что точно так же поступает и MVC и конкретная реализация — Swing и даже принцип привожу на котором это основано, почитай на досуге. Так понятнее?
A>А вот это уже просто не правда.
Ну ты бы разобрался что ли, прежде чем столь громкими словами кидаться..
A> View подписывается на события модели, но при этом сам никакого интерфейса не предоставляет.
А как по твоему View с контроллером/презентером взаимодействует? Голубиной почной? Хинт: возможность брать данные у модели и наличие интерфейса — ортогональные вещи..
А впрочем, что я распинаюсь, мне-то ты все равно не поверишь, просто из принципа. Спорь лучше с википедией. Обрати внимание на диаграму MVC в верхнем правом углу, там очень хорошо показано кто как и с кем взаимодействует, с коментариями. Представление знает только о модели, контроллер знает и о модели и о представлении, модель не знает ни о ком. Дальше разжевать или понятно?
A> Рома, ЛОЛ, какой ты тупой" лично на меня никакого впечатления не произвели.
Что-ты, Рома, никакой попытки произвести впечатление — это просто искреннее недоумение нелепостью предъявленых претензий..
A>Паттерн MVC не требует от View реализации каких бы то ни было интерфейсов.
Ты под интерфейсом что понимаешь? MVC требует, чтобы контроллер знал о презентере, но не наоборот.
Если же речь о ключевом слове interface, то да, не требует, но чем это черевато я в статье показал, можешь еще раз перечитать.. Еще один хинт — view меняется гораздо чаще чем любой другой компонент триады.
A>Так что всё дальнейшее так же не верно.
Что дальнейшее?
A>Точка входа это не метод. Метод с факсированными значениями парметров так же не является точкой входа.
А что является? Я долго от тебя пытался этого добиться, но ответа так и не получил.
A>bool test = ci1 == ci2; // Бодягин не верит, но тут будет true.
И кто из нас после этого приписками занимается?
A>GetCultureInfo(1049) и GetCultureInfo("ru-RU") это одна и та же точка входа, но разные методы с разными параметрами.
Да байта ради, но ты-то утверждал обратное, что один метод означает несколько разных "точек входа". Так что причем здесь это?
Ром, еще раз говорю — не передергивай, не умеешь..
A> Мне за твоё обучение никто не платит.
Давай я лучше тебе платить буду, чтобы ты других не учил... Право-слово, мне же дешевле выйдет..
Здравствуйте, IB, Вы писали:
A>>Windows.Forms хотя и использует WinAPI, но являясь слишком тонкой обёрткой не изменило ситуацию в корне. IB>А кто сказал, что должно было изменить? Ром, ты хотя бы себя читай, что ли.. )
Не должно, но могло.
IB>Рома, не ищи проблемы у меня, разберись сначала со своими..
У меня проблем нет
IB>Например, с внимательным чтением — чтобы показать, что MVP не повышает связность, я говорю, что точно так же поступает и MVC и конкретная реализация — Swing и даже принцип привожу на котором это основано, почитай на досуге. Так понятнее?
Ты как-то странно опустил аргумент про BeginUpdate/EndUpdate, как будто его и не было вовсе. И про то что обощённый IView не слишком удобная штука. Я уже не говорю о том, что данные во View в результате такой реализации будут копиями (ща ещё про глубокое копирование поговорим) данных в Model (нерациональное расходование памяти, бла-бла-бла). Пока ты тут теоретизируешь, я уже от MVP на собственно опыте отказался Буду краток — неэффективно. Слишком много сопутствующего кода надо реализовывать для переливания из пустого в порожнее, разного рода передачи данных из одних классов в другие.
A>>View подписывается на события модели, но при этом сам никакого интерфейса не предоставляет. IB>А как по твоему View с контроллером/презентером взаимодействует? Голубиной почной? Хинт: возможность брать данные у модели и наличие интерфейса — ортогональные вещи..
Интерефйс там просто не нужен. А раз не нужен, то и реализовывать его не к чему.
IB>А впрочем, что я распинаюсь, мне-то ты все равно не поверишь, просто из принципа. Спорь лучше с википедией. Обрати внимание на диаграму MVC в верхнем правом углу, там очень хорошо показано кто как и с кем взаимодействует, с коментариями. Представление знает только о модели, контроллер знает и о модели и о представлении, модель не знает ни о ком. Дальше разжевать или понятно?
Мне вполне это всё понятно, пойми и ты что там означают сплошные линии, а что пунктирные.
A>>Паттерн MVC не требует от View реализации каких бы то ни было интерфейсов. IB>Ты под интерфейсом что понимаешь? MVC требует, чтобы контроллер знал о презентере, но не наоборот. IB>Если же речь о ключевом слове interface, то да, не требует, но чем это черевато я в статье показал, можешь еще раз перечитать.. Еще один хинт — view меняется гораздо чаще чем любой другой компонент триады.
Под интерфейсом я понимаю то что в .Net называется интерфейсом, так как примеры у тебя на C#. Если быть совсем уж точным, то конечно View должен мочь обновлятся. Другое дело как это сделать. В .Net модель может предоставлять набор XyzChanged событий, на которые все кому надо подпишутся. В каких-то других условиях возможно пришлось бы реализовать IView с методом UpdateXyz, но уж точно не стоит прегонять во View копию данных через SetXyz. Ещё повторюсь почему это плохо:
Мы вынуждены обощённо передавать во View все данные модели, либо реализовать систему оповещения какая часть данных нужна.
Мы вынуждены извне поддерживать целостность данных во View.
A>>Точка входа это не метод. Метод с факсированными значениями парметров так же не является точкой входа. IB>А что является? Я долго от тебя пытался этого добиться, но ответа так и не получил.
Отвечаю — абстракция, некоторый глобальный механизм получения одного и того же экземпляра некоторого класса. В каноническом виде она действительно совпадает с методом Instance() и только лишь совпадает. В реальной реализации "расширенного синглтона" у неё может не быть чёткого физического представления.
A>>GetCultureInfo(1049) и GetCultureInfo("ru-RU") это одна и та же точка входа, но разные методы с разными параметрами. IB>Да байта ради, но ты-то утверждал обратное, что один метод означает несколько разных "точек входа". Так что причем здесь это?
Я утверждал, что один метод с параметром это может быть несколько точек входа. То что Method(Int16) это всегда 65536 точек входа конечно же бред, который ты мне почему-то приписывал.
Если на примере с CultureInfo ты наконец-то понял что я имел ввиду, я очень рад.
Здравствуйте, adontz, Вы писали:
A>Интерефйс там просто не нужен. А раз не нужен, то и реализовывать его не к чему.
Насколько понял, в споре сравнивается с одной стороны активная модель MVC, которая оповещает представления, а с другой стороны, неактивная модель MVP, оповещение представления об изменении которой берет на себя предъявитель. Не вижу причин, почему не имеют право на жизнь каждый из этих вариантов.
Оповещение активной моделью представления в Java, к примеру, производится посредством шаблона проектирования Observer, когда представления реализуют интерфейс подписки, по которому модель и производит оповещение, то есть интерфейс в любом случае имеет место. То, что в C# событийная модель работает не на интерфейсах, а на делегатах — собственно сам шаблон проектирования MVP не меняет, да и по сути является функциональным аналогом.
A>Паттерн MVC не требует от View реализации каких бы то ни было интерфейсов.
Гм... туда же, см. выше.
A>Под интерфейсом я понимаю то что в .Net называется интерфейсом, так как примеры у тебя на C#. Если быть совсем уж точным, то конечно View должен мочь обновлятся. Другое дело как это сделать. В .Net модель может предоставлять набор XyzChanged событий, на которые все кому надо подпишутся. В каких-то других условиях возможно пришлось бы реализовать IView с методом UpdateXyz, но уж точно не стоит прегонять во View копию данных через SetXyz. Ещё повторюсь почему это плохо: A> Мы вынуждены обощённо передавать во View все данные модели, либо реализовать систему оповещения какая часть данных нужна. A> Мы вынуждены извне поддерживать целостность данных во View.
Так и не понял, в чем координальное различие оповещения из модели представления и оповещения из предъявителя представления? В любом варианте можно организовать оповещение об изменении любой части модели: в первом случае изменится интерфейс (или делегаты в C#) подписки представления на изменения модели, во втором случае интерфейс представления, по которому оно принимает события изменения модели от предъявителя.
J>Вот не могу всетаки полностью мозгами принять подход MVP, тяжело после MVC перестроиться
J>Никак не соображу блин как в подход предлагаемый MVP может вписаться биндинг, т.е. автоматическая J>привязка данных к контролу ...
в ASP.NET мы завели два метода в IView: Form2Data и Data2Form, и с помощью библиотеки oт MetaCommunication (см. проекты) привязываем уже в самой разметке aspx/ascx.
Для winforms что-то подобное (но точно не скажу, не смотрел) умеет BLToolkit (опять же в проекты).
Здравствуйте, adontz, Вы писали:
A>Не должно, но могло.
Ну и? К чему это?
A>У меня проблем нет
Ага, вижу..
A>Ты как-то странно опустил аргумент про BeginUpdate/EndUpdate, как будто его и не было вовсе.
Это не аргумент, это твои .. эээ. теоретические построения.
A> И про то что обощённый IView не слишком удобная штука.
Кто тебе сказал, что он обобщенный? Ну вот откуда ты это взял, расскажи пожалуйста? Ну не смешно уже даже, пожалуйста, в очередной раз очень тебя прошу, читай внимательно, а то приходится одно и то же по десять раз повторять.
A> Я уже не говорю о том, что данные во View в результате такой реализации будут копиями
Предложи альтернативную, расскажи, как ты View собираешься обновлять.
A>(нерациональное расходование памяти, бла-бла-бла).
A> Пока ты тут теоретизируешь, я уже от MVP на собственно опыте отказался
A>Интерефйс там просто не нужен. А раз не нужен, то и реализовывать его не к чему.
Перечитай еще раз соответствующий раздел в статье, внимательно... Тебе-то он может быть и не нужен, а вот во всех внятных реализациях, (e. g. тот же Swing) он присутствует, и там сказано почему.
A>Мне вполне это всё понятно,
Сомневаюсь, было бы понятно, не спорил бы...
A> пойми и ты что там означают сплошные линии, а что пунктирные.
Советуюу тебе обратить пристальне внимание на стрелочки..
A> Если быть совсем уж точным, то конечно View должен мочь обновлятся. Другое дело как это сделать. В .Net модель может предоставлять набор XyzChanged событий, на которые все кому надо подпишутся. A> В каких-то других условиях возможно пришлось бы реализовать IView с методом UpdateXyz, но уж точно не стоит прегонять во View копию данных через SetXyz.
Еще раз, для младшего сержантского состава.. Интерфейса и события — независимые сущности, это значит не пересекающиеся и не взаимоисключающие, они существуют одновременно и осуществляют обмен данными в разных направлениях. Почему ты валишь все в одну кучу?
События View оповещают Контроллер о том, что View изменился (то что ты описываешь), с помощю же интерфейса Контроллер обновляет View и считывает изменения. Такая схема позволяет View на парится о том, что за Контроллер с ним работает — уменьшает связность. =)
Почему приходится азы разжевывать?
A>Ещё повторюсь почему это плохо: A> Мы вынуждены обощённо передавать во View все данные модели, либо реализовать систему оповещения какая часть данных нужна.
Кто тебя к этому вынудил? Во View надо передавать только те данные, которые нужны конкретному View.
Зачем тебе понадобилась система оповещения?
A> Мы вынуждены извне поддерживать целостность данных во View.
Для чего? Какие у тебя могут появиться проблемы с целостностью из-за наличия интерфейса?
A>Отвечаю — абстракция, некоторый глобальный механизм получения одного и того же экземпляра некоторого класса.
Почему именно одного и того же? Если это абстракция — почему ты ограничиваешь термин "точка доступа" конкретным паттерном?
A>В реальной реализации "расширенного синглтона" у неё может не быть чёткого физического представления.
Что такое "расширеный" синглтон? Как может не быть четкого физического представления у ключевой сущности паттерна?
Ты, похоже сам уже запутался..
A>Я утверждал, что один метод с параметром это может быть несколько точек входа.
Ага. Так в каких же случая метод с параметом — несколько точек доступа, а в каких одна? Могу я глядя на метод, но не зная ее реализации, утверждать, что это вот одна "точку доступа", а здесь вот у нас их на самом деле несколько?
Здравствуйте, IB, Вы писали:
IB>События View оповещают Контроллер о том, что View изменился (то что ты описываешь), с помощю же интерфейса Контроллер обновляет View и считывает изменения. Такая схема позволяет View на парится о том, что за Контроллер с ним работает — уменьшает связность. =)
Сделал несколько иначе. Предъявитель по сути должен уметь работать с несколькими представлениями, которые хотят отображать одну и ту же модель, которой управляет предъявитель. Поэтому все представления при инициализации сами обращается к нужному им предъявителю, соответственно имеют прямые ссылки на него. Работают с ними не по событиям, как у вас в статье, а напрямую по шаблону проектирования Command. А вот предъявитель уже поэтому не "заморачивается" тем, какие именно представления с ним работают — оповещение организовано почти как и у вас по шаблону проектирования Observer, то есть предъявитель является публикатором, на который подписываются представления — подписчики: предъявитель изменяет модели и по завершению производит оповещение всех подписанных представлений. Вроде бы ничему не противоречит такое построение, как по-вашему?
Здравствуйте, rsn81, Вы писали:
A>>Под интерфейсом я понимаю то что в .Net называется интерфейсом, так как примеры у тебя на C#. Если быть совсем уж точным, то конечно View должен мочь обновлятся. Другое дело как это сделать. В .Net модель может предоставлять набор XyzChanged событий, на которые все кому надо подпишутся. В каких-то других условиях возможно пришлось бы реализовать IView с методом UpdateXyz, но уж точно не стоит прегонять во View копию данных через SetXyz. Ещё повторюсь почему это плохо: A>> Мы вынуждены обощённо передавать во View все данные модели, либо реализовать систему оповещения какая часть данных нужна. A>> Мы вынуждены извне поддерживать целостность данных во View. R>Так и не понял, в чем координальное различие оповещения из модели представления и оповещения из предъявителя представления? В любом варианте можно организовать оповещение об изменении любой части модели: в первом случае изменится интерфейс (или делегаты в C#) подписки представления на изменения модели, во втором случае интерфейс представления, по которому оно принимает события изменения модели от предъявителя.
Простой пример, хотя и слегка надуманный.
Пусть у нас в качестве данных двумерная точка (System.Drawing.Point если угодно). Так случилось, что меняются за раз обе её координаты. Пусть в начале координаты (3;7), а стали (5; 6). В MVC модель отшлёт виду оповещение CoordsChanged, вид прочтёт за раз обе координаты, и отрисует точку в новом положении. В MVP сложнее, оповещений нет. Но и сказать виду SetX(5); SetY(6) нельзя, потому что между этми вызовами вид отрисует точку по координатам (5;7). Надо делать BeginUpdate, SetX, SetY, EndUpdate. Кроме того виду может понадобится только X-координата. В MVC только она видом и считывается, в MVP информация о том что именно надо виду теряется и приходится перегонять туда обе координаты, даже если в этом нет необходимости.
Понятно, что объект Point слишком мал и пример выглядит странно, но представьте себе что у нас более сложные композитные данные.
Здравствуйте, adontz, Вы писали:
A>Пусть у нас в качестве данных двумерная точка (System.Drawing.Point если угодно). Так случилось, что меняются за раз обе её координаты. Пусть в начале координаты (3;7), а стали (5; 6). В MVC модель отшлёт виду оповещение CoordsChanged, вид прочтёт за раз обе координаты, и отрисует точку в новом положении. В MVP сложнее, оповещений нет.
Это только в примере автора так, для наглядности этого было достаточно. Выше писал, что предъявитель может в принципе оповещать представления, почти абсолютно повторяя оповещение представлений моделью в MVC. Какая собственно разница-то?
A> Но и сказать виду SetX(5); SetY(6) нельзя, потому что между этми вызовами вид отрисует точку по координатам (5;7). Надо делать BeginUpdate, SetX, SetY, EndUpdate. Кроме того виду может понадобится только X-координата. В MVC только она видом и считывается, в MVP информация о том что именно надо виду теряется и приходится перегонять туда обе координаты, даже если в этом нет необходимости.
Гм... В MVC модель рассылает события методами SetX, SetY, SetBoth (интерфейс/делегат реализуют представления), аналогом в MVP может выступить (если говорить о примере автора) одноименные методы интерфейса IView: SetX, SetY, SetBoth (опять же данный интерфейс реализуют представления). Где разница? В упор не вижу.
Здравствуйте, rsn81, Вы писали:
R>Гм... В MVC модель рассылает события методами SetX, SetY, SetBoth (интерфейс/делегат реализуют представления), аналогом в MVP может выступить (если говорить о примере автора) одноименные методы интерфейса IView: SetX, SetY, SetBoth (опять же данный интерфейс реализуют представления). Где разница? В упор не вижу.
Я боялся, что простота данных введёт в заблеждение. Вобщем-то у меня нету никакого SetBoth.
Это когда два компонента руки тянутся это написать, а когда их, скажем 4? 64 разных метода? Нет, в результате вернёмся к операторным скобкам BeginUpdate/EndUpdate.
Здравствуйте, IB, Вы писали:
A>>Ты как-то странно опустил аргумент про BeginUpdate/EndUpdate, как будто его и не было вовсе. IB>Это не аргумент, это твои .. эээ. теоретические построения.
ГЫ. Ударились в демагогию? Покажи мне реализацию обновления сложной модели без BeginUpdate/EndUpdate. Я тут про точку рядом написал.
A>> И про то что обощённый IView не слишком удобная штука. IB>Кто тебе сказал, что он обобщенный? Ну вот откуда ты это взял, расскажи пожалуйста? Ну не смешно уже даже, пожалуйста, в очередной раз очень тебя прошу, читай внимательно, а то приходится одно и то же по десять раз повторять.
Он обобщённый потому что интерфейс который реализуют все виды.
IB>Предложи альтернативную, расскажи, как ты View собираешься обновлять.
Например считывать из модели по мере необходимости. Про virtual list-view слыхал? А про DataSource вместо Items.Add?
IB>События View оповещают Контроллер о том, что View изменился (то что ты описываешь),
View изменился?! Мда, приехали. Я такой бред никогда не нёс.
IB>Кто тебя к этому вынудил? Во View надо передавать только те данные, которые нужны конкретному View. IB>Зачем тебе понадобилась система оповещения?
Затем что ты не знаешь заранее какие данные нужны конкретному View.
A>> Мы вынуждены извне поддерживать целостность данных во View. IB>Для чего? Какие у тебя могут появиться проблемы с целостностью из-за наличия интерфейса?
См пример про точку в соседней ветке.
A>>Отвечаю — абстракция, некоторый глобальный механизм получения одного и того же экземпляра некоторого класса. IB>Почему именно одного и того же?
Потому что это Синглтон
IB>Что такое "расширеный" синглтон? Как может не быть четкого физического представления у ключевой сущности паттерна? IB>Ты, похоже сам уже запутался..
Я не запутался. Есть синглтон из "Банды четырёх", где предлагается его расширить чтобы возвращать несколько экземпляров. Вот о таком расширенном я и говорю. А включать дурака не надо, мы это последние несколько дней обсуждаем. С чего это тебе именно сегодня вдруг стал непонятен термин расширеный синглтон?
IB>Ага. Так в каких же случая метод с параметом — несколько точек доступа, а в каких одна?
Зависит от реализации метода.
IB>Могу я глядя на метод, но не зная ее реализации, утверждать, что это вот одна "точку доступа", а здесь вот у нас их на самом деле несколько?
Здравствуйте, adontz, Вы писали:
A>Я боялся, что простота данных введёт в заблеждение. Вобщем-то у меня нету никакого SetBoth.
Если нет, то и в случае MVC, и в случае MVP одно и тоже, будет, как вы говорите, эти сотые доли секунд, когда представление обновит графический примитив отображающий одну координату, но еще не успеет обновить отображение другой координаты. И опять же вопрос: где тут разница, якобы на основании которой вы ставите MVC выше MVP?
Здравствуйте, adontz, Вы писали:
A>В MVP сложнее, оповещений нет. Но и сказать виду SetX(5); SetY(6) нельзя, потому что между этми вызовами вид отрисует точку по координатам (5;7). Надо делать BeginUpdate, SetX, SetY, EndUpdate. Кроме того виду может понадобится только X-координата. В MVC только она видом и считывается, в MVP информация о том что именно надо виду теряется и приходится перегонять туда обе координаты, даже если в этом нет необходимости.
Кто сказал? Опять все претензии из-за того, что невнимательно прочитал?
1. От того, что нет оповещений ничуть сложнее не стало — изменения в модель попадают через презентер, значит он знает, что изменения были внесены и совершенно спокойно может обновить представление, я писал об этом уже несколько раз.
2. Опять-таки я несколько раз упоминал о том, что Представление не бязательно должно работать с примитивными типами, если очень нужно то в интерфейсе вполне может быть описан метод SetPoint(Point p), хотя это и усложнит view.
3. В MVP вполне могут быть оповещения представлений моделью, о чем опять-же сказано в статье, но в подавляющем большинстве случаев это приведет лишь к неоправданному навешиванию на представление лишней логики.
4. При изменении модели у медиатора в классическом MVP ровно столько же информации сколько и у презентера, следовательно он так же в состоянии обновить только ту часть представления, которая необходима. Это я писал уже непосредственно тебе.
A>Понятно, что объект Point слишком мал и пример выглядит странно, но представьте себе что у нас более сложные композитные данные.
Болеее сложные композитные данные работают с более сложными композитными триадами, все эти случаи я уже описывал.
Здравствуйте, rsn81, Вы писали:
R> Предъявитель по сути должен уметь работать с несколькими представлениями, которые хотят отображать одну и ту же модель, которой управляет предъявитель.
Угу. Именно поэтому вводится обобщенный интерфейс для Представления и для вывода информации в нужном виде достаточно всего лишь реализовать этот интерфейс. В зависимости от ситуации Презентер имеет дело с конкретной реализацией этого интерфейса, но с какой именно ему совершенно все равно.
R> Поэтому все представления при инициализации сами обращается к нужному им предъявителю, соответственно имеют прямые ссылки на него.
Это плохо тем, что во-первых, вносит лишнюю логику в Пердставление. По сути логика работы с данными размазывается между Представлением и Презентером, в то время как основная цель паттерна сделать Представление как можно проще и по возможности сосредоточить всю логику отображения в презентере.
Во-вторых, появляется лишний раунд трип при обновлении Представления — сначала в Представление отсылается событие, а потом оно лезет обновляться.
В третих, это здорово уменьшает шанс повторного использования того же Представления с другим Презентером.
Ведь не случайно, даже в классическом шаблоне именно контроллер знает о представлении, но не наоборот.
Здравствуйте, rsn81, Вы писали:
R>Здравствуйте, adontz, Вы писали:
A>>Я боялся, что простота данных введёт в заблеждение. Вобщем-то у меня нету никакого SetBoth. R>Если нет, то и в случае MVC, и в случае MVP одно и тоже
Не будет. представление в процессе самостоятельного считывания данных может себя не перерисовывать.
R>эти сотые доли секунд
Грубая ошибка. Сложное представление может обновлятся за времена порядка секунд. Я работал с географическими картами, так там DirectX/OpenGL пришлось задействовать, а иначе ужас какая скорость 0.3-0.5 FPS.
R>И опять же вопрос: где тут разница, якобы на основании которой вы ставите MVC выше MVP?
Здравствуйте, IB, Вы писали:
IB>1. От того, что нет оповещений ничуть сложнее не стало — изменения в модель попадают через презентер, значит он знает, что изменения были внесены и совершенно спокойно может обновить представление, я писал об этом уже несколько раз.
Обновить — да, обновить эффективно — гораздо сложнее.
IB>2. Опять-таки я несколько раз упоминал о том, что Представление не бязательно должно работать с примитивными типами, если очень нужно то в интерфейсе вполне может быть описан метод SetPoint(Point p), хотя это и усложнит view.
Дело не в том, что это усложнит View. Дело в том, что при наличии 5-6 компонент всех вариаций методов ты просто не напишешь.
IB>3. В MVP вполне могут быть оповещения представлений моделью, о чем опять-же сказано в статье, но в подавляющем большинстве случаев это приведет лишь к неоправданному навешиванию на представление лишней логики.
Так уж и неправданному? ООД должен ускоряя разработку программы не слишком тормозить исполнение.
IB>4. При изменении модели у медиатора в классическом MVP ровно столько же информации сколько и у презентера, следовательно он так же в состоянии обновить только ту часть представления, которая необходима. Это я писал уже непосредственно тебе.
Когда я говорю об изменении необходимой части представления я имею ввиду не передачу в представление diff(old, new), а тот факт что представление может использовать только часть модели.
Например у меня есть модель — географически даные. MapView рисует карту (Bitmap), а на ней города (List<Town>) и пути по которым двигались автомобили и есть TownsView который выводит в столбик список городов. Если изменились пути движения автомобилей, то TownsView на это глубоко наплевать. И уж точно не стоит передавать туда новые пути.
Здравствуйте, adontz, Вы писали:
A>Покажи мне реализацию обновления сложной модели без BeginUpdate/EndUpdate. Я тут про точку рядом написал.
Вот я тебе там и ответил. Плюс, еще есть вариант с Refresh-ем, и это если не вспоминать о том, что "не согласованное" обновление на самом деле не проблема.
A>Он обобщённый потому что интерфейс который реализуют все виды.
Да не все, а только те, которые работают с определенным набором данных. Презентер вполне может работать с несколькими IView для разных данных и с моделью могут иметь дело несколько презентеров для разных задачь...
Это не очевидно?
Ром, если бы ты свои вопросы оформлял не в виде наездов, то я бы объяснил все гораздо раньше и подробнее, а то только по косвенным признакам приходится вылавливать в чем ты не разобрался...
A>Например считывать из модели по мере необходимости.
И что тебе мешает делать то же самое в MVP?
A>View изменился?! Мда, приехали. Я такой бред никогда не нёс.
Так у тебя и View еще никогда не меняется? А данные ты как редактируешь?
A>Затем что ты не знаешь заранее какие данные нужны конкретному View.
Почему?
A>Потому что это Синглтон
Ответ неверный.
A>Я не запутался.
Запутался.
A> Вот о таком расширенном я и говорю.
Ага, Ок. Я просто думал, что это ты о своей хитрой реализации..
A> С чего это тебе именно сегодня вдруг стал непонятен термин расширеный синглтон?
Да он мне никогда не был понятен, как и многие другие твои термины, типа "точки доступа". Есть просто синглтон — паттерн который позволяет контролировать число экземпляров конкретного класса.
IB>>Могу я глядя на метод, но не зная ее реализации, утверждать, что это вот одна "точку доступа", а здесь вот у нас их на самом деле несколько? A>Нет, не можешь.
И ты здесь никакого косяка не видишь? Все нормально?
возвращать несколько экземпляров
(c) Рома.
То есть все-таки экземпляров, а не точек доступа? Я рад, что ты наконец осознал свое заблуждение, что ж, вопрос с синглтоном можно считать закрытым..
Ну право-слово, твое желание найти у меня ошибки лишь демонстрирует твое .... эээ.. слабое знание предмета )
Мы уже победили, просто это еще не так заметно...
ООД должен ускоряя разработку программы не слишком тормозить исполнение.