Re[2]: Model-View-Controller в .Net
От: IB Австрия http://rsdn.ru
Дата: 25.06.07 20:37
Оценка:
Здравствуйте, Aviator, Вы писали:

A>Ну и в чём прикол?

Приколы здесь: http://rsdn.ru/forum/group/humour.aspx

A>Любая попытка реализовать MVC с описанным инструментарием приведёт к описанному архитектурному решению.

Во-первых, "все обобщения ложны" — несколькми топиками ниже есть еще одна статья про днный паттерн с тем же инструментарием, где описан другой подход. А во-вторых, цели показать супероригинальную реализацию MVC не ставилось, цель указана в названии статьи — реализация паттерна MVP в .Net. В чем суть претензии-то?

A> Собственно говоря, врятли кто то захочет реализовывать названную автором "типичную схему" (хотя что в ней типичного )

Собственно говоря, в предложенной статье именно такая схема и реализована. А типичного в ней то, что она, в том или ином виде, характерна для любой реализации MVC.
Ты действительно понял какая именно реализация предлагается и что за схема имелаь ввиду?
Мы уже победили, просто это еще не так заметно...
Re[3]: Model-View-Controller в .Net
От: Aviator  
Дата: 26.06.07 08:07
Оценка:
Здравствуйте, IB, Вы писали:
IB>Ты действительно понял какая именно реализация предлагается и что за схема имелаь ввиду?
Думаю что вполне .
Re[3]: Model-View-Controller в .Net
От: Aviator  
Дата: 26.06.07 08:14
Оценка:
Здравствуйте, IB, Вы писали:

IB>Собственно говоря, в предложенной статье именно такая схема и реализована. А типичного в ней то, что она, в том или ином виде, характерна для любой реализации MVC.

В статье представление выступает некоторомы медиатором между моделью и видом. Вид содержит только то, что касается непосредственно ГУИ. Ненавязчивый вопрос, а что, есть другие варианты реализации? Если отбрсить детали, то по-моему всё сводится к такому варианту .
Re[4]: Model-View-Controller в .Net
От: IB Австрия http://rsdn.ru
Дата: 26.06.07 08:59
Оценка:
Здравствуйте, Aviator, Вы писали:

A>В статье представление выступает некоторомы медиатором между моделью и видом. Вид содержит только то, что касается непосредственно ГУИ. Ненавязчивый вопрос, а что, есть другие варианты реализации?

Как минимум, выделяют три: Passive View, Supervising Controller, Presentation Model. В статье модель больше всего приближенная к PV.

A> Если отбрсить детали, то по-моему всё сводится к такому варианту .

Если отбросить детали, то все сведется к одной большой красной кнопке.
... << RSDN@Home 1.2.0 alpha rev. 673>>
Мы уже победили, просто это еще не так заметно...
Re[5]: Model-View-Controller в .Net
От: Aviator  
Дата: 26.06.07 09:44
Оценка:
Здравствуйте, IB, Вы писали:

IB>Здравствуйте, Aviator, Вы писали:


A>>В статье представление выступает некоторомы медиатором между моделью и видом. Вид содержит только то, что касается непосредственно ГУИ. Ненавязчивый вопрос, а что, есть другие варианты реализации?

IB>Как минимум, выделяют три: Passive View, Supervising Controller, Presentation Model. В статье модель больше всего приближенная к PV.
А ещё пока нет Supervising Active Controller? Это я к тому, что в любом проекте в любом случае MVC будет отличаться от каноническоого, по моему паттерн — это архитектурный подход, а не детально, вплоть до типов параметров методов, расписанное техническое решение. Или ещё можно начать дискуссию, что лучше — реализовывать колбэки от View через события или интерфейсы? Тоже очень важный момент, тут наверно ещё парочку "разновидностей паттерна" можно придумать .
Re[6]: Model-View-Controller в .Net
От: rsn81 Россия http://rsn81.wordpress.com
Дата: 26.06.07 10:28
Оценка: :)
Здравствуйте, Aviator, Вы писали:

A>Или ещё можно начать дискуссию, что лучше — реализовывать колбэки от View через события или интерфейсы?

Прочитайте всю тему и удивитесь: а ведь такая дискуссия действительно поднималась.
... << RSDN@Home 1.2.0 alpha rev. 679>>
Re[7]: Model-View-Controller в .Net
От: Aviator  
Дата: 26.06.07 10:42
Оценка:
Здравствуйте, rsn81, Вы писали:

R>Здравствуйте, Aviator, Вы писали:


A>>Или ещё можно начать дискуссию, что лучше — реализовывать колбэки от View через события или интерфейсы?

R>Прочитайте всю тему и удивитесь: а ведь такая дискуссия действительно поднималась.
жесть .
Re[6]: Model-View-Controller в .Net
От: IB Австрия http://rsdn.ru
Дата: 26.06.07 11:07
Оценка:
Здравствуйте, Aviator, Вы писали:

A> Это я к тому, что в любом проекте в любом случае MVC будет отличаться от каноническоого, по моему паттерн — это архитектурный подход, а не детально, вплоть до типов параметров методов, расписанное техническое решение.

У тебя один архитектурный подход на все случаи жизни? Это я к тому, что Document-View — это тоже MVC. Отличается он по твоему от классического паттерна — или "одня фигня"?
... << RSDN@Home 1.2.0 alpha rev. 673>>
Мы уже победили, просто это еще не так заметно...
Re[7]: Model-View-Controller в .Net
От: Aviator  
Дата: 26.06.07 11:30
Оценка:
Здравствуйте, IB, Вы писали:

IB>Здравствуйте, Aviator, Вы писали:


A>> Это я к тому, что в любом проекте в любом случае MVC будет отличаться от каноническоого, по моему паттерн — это архитектурный подход, а не детально, вплоть до типов параметров методов, расписанное техническое решение.

IB>У тебя один архитектурный подход на все случаи жизни? Это я к тому, что Document-View — это тоже MVC. Отличается он по твоему от классического паттерна — или "одня фигня"?
отличается, это упрощение. Я как раз наоброт говорил, что в каждом случае конкретном случае своя реализауия, своя вариация. Зависит от текущей задачи и ряда условий.
Re[8]: Model-View-Controller в .Net
От: IB Австрия http://rsdn.ru
Дата: 26.06.07 12:56
Оценка: +1
Здравствуйте, Aviator, Вы писали:

A>отличается, это упрощение.

Так это другой архитектурный подход или тот же самый?

A>Я как раз наоброт говорил, что в каждом случае конкретном случае своя реализауия, своя вариация. Зависит от текущей задачи и ряда условий.

Ну и к чему ты это говорил? В чем суть-то претезнии?
... << RSDN@Home 1.2.0 alpha rev. 673>>
Мы уже победили, просто это еще не так заметно...
Re[13]: Model-View-Controller в .Net
От: chocho Россия  
Дата: 30.04.08 14:26
Оценка:
Здравствуйте, IB, adontz и остальные участники )

Сил нет дальше читать, хочется высказаться...
мало ли кто ещё будет читать тред, всё-таки дискуссия интересная...

Пример: есть virtual ListView с миллионом айтомов, юзер по ним может даблкликать, и рядом, допустим, просто ListView, отображающий 10 последних выбранных айтомов (history).
Причём history айтомы являются частью бизнес логики (например, они сохраняются между запусками апликухи).

В модели MVC:
юзер ищет нужный айтем, данные биндятся с моделью, благо в MVC на рид к модели обращаться нормально->
юзер даблкликает->
контроллер получает команду АктивэйтАйтем(реализация, например, паттерном "команда")->
контроллер, отвечает за поведение и, соответственно, преобразовывает команду в два действия над моделью:
активизировать айтем #1007, добавить айтем в history->
видов два (ну нужно два, например, вид history item-ов ещё где-нить используется):
один подписан на m.ItemActvated, другой на m.History.ItemAdded->
1)в первом виде: update-ятся контролы, которые должны измениться при активизации айтема
2)во втором: добавляется ещё один элемент в history listview. (Нужная информация берётся из аргументов с которыми райзилось событие в модели или из самой модели)

Имхо всё прозрачно и непротиворечиво,

Как быть в случае MVP:
1)Если датабиндинг оставлять как есть, то вид будет взаимодействовать и напрямую с моделью и изменяться презентером...

2)Обе вьюшки, конечно, можно привести к одному интерфейсу
public interface IView
{
    void ActivateItem(Item i);
}

Соответственно, решреш будет происходить в обоих вьюшках, в одной update нужных контролов, в другой — добавление айтема в хистори. Вот только допустим, появляется ещё один ListView c айтамами которые могут активизироваться. Добавить вью для этого listview в тот же презентер означает, что для этой вьюшки будет вызываться ActivateItem(Item i) c несуществующим в нём айтемом.
Решение, видимо — другой презентер (вьюшка нового listview и вьюшка history). Но при каких-то действиях с айтамами в history listview презентеры будут два раза делать одни и те же действия с моделью...

3)Что нужно сделать чтобы представление отобразило другую подобную модель?
Нужно подменить модель во всех презентерах, к тому же если в MVC её интерфейс (всмысле в коде) должен совпадать по интерфейсам событий (в модели проталкивания), то тут — по интерфейсу модели (те самые фаренгейты и цельсии).


Вообщем, имхо, если MVC использовать канонически, не совмещая контроллер и вью, то она лучше выполняет базовые гарантии:
1) Модель независима от контроллера и представления.
2) Вид гарантирует правильное и своевременное обновление при изменении в модели.
3) Вид способен отображать модели с одинаковым интерфейсом.

Возможно я не до конца понял MVP и было бы здорово просто описать его в цепочке событий для нескольких вью... (презентеров)
"Не морочьте мне голову. Полыхаев" ©
Re[14]: Model-View-Controller в .Net
От: rsn81 Россия http://rsn81.wordpress.com
Дата: 04.05.08 16:07
Оценка:
Здравствуйте, chocho, Вы писали:

C>Вообщем, имхо, если MVC использовать канонически, не совмещая контроллер и вью, то она лучше выполняет базовые гарантии:

C>1) Модель независима от контроллера и представления.
Нет, просто ее зависимость минимальна. В MVC наиболее удобным является использование активной модели: от нее требуется соблюдение контракта Observer. С другой стороны, в MVP удобнее использовать пассивную модель: от нее не требуется ничего. Количество связей, пусть даже ослабленных, в MVP в итоге меньше.

C>2) Вид гарантирует правильное и своевременное обновление при изменении в модели.

А в MVP в чем проблемы?

C>3) Вид способен отображать модели с одинаковым интерфейсом.

Что вы имеете в виду?

Про MVC vs MVP: субъективно считаю, что на desktop удобнее MVC, а на вебе — MVP.

C>Возможно я не до конца понял MVP и было бы здорово просто описать его в цепочке событий для нескольких вью... (презентеров)

Возможно, не до конца понял глубину мысли... Тем не менее, зачем нагружать предъявитель обработкой событий выделения элементов в каком-то графическом виде? В принципе, наверно можно и так, только лично мне непонятна надобность. Тыкнул пользователь в строчку таблицы — от этого, что, модель, данные которой эта строчка отображает, как-то изменилась? Выделенность элемента таблицы — это свойство Table, пусть TableItem, но уж никак не Model, что собственно и реализовано во всех графических библиотеках. У меня представления спокойно подписываются на подобные события, генерируемые друг другом, практически напрямую... точнее через некоторый диспетчер: если представлению интересны выделения элементов Employee, оно явно это говорит диспетчеру при подписке на соответствующие события. Хм... с другой стороны, быть может никогда не приходила мысль пихать этот функционал в MVC/MVP, просто потому что везде этот функционал находил уже готовым.
Re[15]: Model-View-Controller в .Net
От: chocho Россия  
Дата: 04.05.08 16:52
Оценка:
Здравствуйте, rsn81, Вы писали:

R>Здравствуйте, chocho, Вы писали:


Нет, просто ее зависимость минимальна. В MVC наиболее удобным является использование активной модели: от нее требуется соблюдение контракта Observer. С другой стороны, в MVP удобнее использовать пассивную модель: от нее не требуется ничего. Количество связей, пусть даже ослабленных, в MVP в итоге меньше.

Например в .NET делегаты\события (то бишь Observer) на уровне платформы, контракт-то в том чтобы модель их оттопырила... делов-то... Тем более, что EventHandler по рекомендациям void handler(Object sender, SomeEventArgs args). Т.е. вьюшке говорится: я модель такая-то, случилось то-то, вот тебе доп.инфа... Это ли не пассивная модель?


C>>2) Вид гарантирует правильное и своевременное обновление при изменении в модели.
R>А в MVP в чем проблемы?

Если вью изменилось, модель измениться, а ну как бизнес-логика изменит какой-нить стейт в модели. Уверенности, что не забудут про рефреш вьюшки нету... а ну как несколько вьюшек, а некоторым и не интересно это изменение. Вообщем мне просто не нравится, что придумывают что-то на пустом месте...

C>>3) Вид способен отображать модели с одинаковым интерфейсом.
R>Что вы имеете в виду?

Модель — обёртка над двумя столбцами в экселе, вью — диаграммы...

R>Про MVC vs MVP: субъективно считаю, что на desktop удобнее MVC, а на вебе — MVP.

вот неплохая статейка... http://www.microsoft.com/Rus/Msdn/Magazine/2008/04/without_forms.mspx
народ из M$ сильно не парится c терминологией, пишет MVC, подразумевает MVP...

C>>Возможно я не до конца понял MVP и было бы здорово просто описать его в цепочке событий для нескольких вью... (презентеров)
R>Возможно, не до конца понял глубину мысли... Тем не менее, зачем нагружать предъявитель обработкой событий выделения элементов в каком-то графическом виде?...

Нет я не о выделении, конечно... ну видимо плохой пример...
"Не морочьте мне голову. Полыхаев" ©
Re[16]: Model-View-Controller в .Net
От: rsn81 Россия http://rsn81.wordpress.com
Дата: 04.05.08 17:47
Оценка:
Здравствуйте, chocho, Вы писали:

C>Например в .NET делегаты\события (то бишь Observer) на уровне платформы, контракт-то в том чтобы модель их оттопырила... делов-то...

А кто говорит, что Observer шибко сложный паттерн? Синтаксический сахар в виде автоматический генерации кода издателя в .NET не отменяет суть паттерна. Аналогично, можно написать обобщенную реализацию Observer на любом языке (или использовать готовую, если такая уже есть в DK, к примеру, в JDK оно есть) и использовать повторно.

C>Тем более, что EventHandler по рекомендациям void handler(Object sender, SomeEventArgs args). Т.е. вьюшке говорится: я модель такая-то, случилось то-то, вот тебе доп.инфа...

С другой стороны, в многопоточном GUI-приложении с Observer-ом не все так просто... как впрочем, также тот нюанс, что Observer потенциально может приводить к утечкам памяти.

Повело сильно в сторону. Просто это к тому, что реалии Observer-а не так уж и тривиальны, как думают некоторые .NET-программисты излишне избалованные синтаксическим сахаром.

C>Это ли не пассивная модель?

Нет, не пассивная. Пассивной моделью может стать любой класс, который понятия не имеет про GUI, к примеру, доступ к перекомпиляции которого вы не имеете, а вот активная модель обязана выполнять контракт издателя — вы не можете просто так взять класс и использовать его как активную модель, придется его научить немного.

C>Если вью изменилось, модель измениться, а ну как бизнес-логика изменит какой-нить стейт в модели. Уверенности, что не забудут про рефреш вьюшки нету... а ну как несколько вьюшек, а некоторым и не интересно это изменение. Вообщем мне просто не нравится, что придумывают что-то на пустом месте...

Что здесь есть здесь "бизнес-логика", пример можно?

C>Модель — обёртка над двумя столбцами в экселе, вью — диаграммы...

Все равно непонятно. Во-первых, чем таблица Excel не представление? Во-вторых, если таблица отображает список сотрудников, то модель — это Employee, а, к примеру, столбец этой таблицы EmployeeNameColumn — представление, отображающее модель Employee
в виде ячейки таблицы с текстом, значение которого берется из Employee.Name. EmployeeSurnameColumn — другое представление, отображающее тот же тип модели — Employee, просто в другом виде. И т.п. Не вижу, с чего вдруг модели быть оберткой над столбцами, она ж не знает о GUI ничего.

C>Нет я не о выделении, конечно... ну видимо плохой пример...

Дайте хороший.
Re[17]: Model-View-Controller в .Net
От: chocho Россия  
Дата: 04.05.08 19:56
Оценка:
Здравствуйте, rsn81, Вы писали:

R>Здравствуйте, chocho, Вы писали:


R>С другой стороны, в многопоточном GUI-приложении с Observer-ом не все так просто... как впрочем, также тот нюанс, что Observer потенциально может приводить к утечкам памяти.

может и приводить, я предпочитаю когда не приводит...

R> Повело сильно в сторону. Просто это к тому, что реалии Observer-а не так уж и тривиальны, как думают некоторые .NET-программисты излишне избалованные синтаксическим сахаром.

ну вот, стыдят... )

R>Нет, не пассивная. Пассивной моделью может стать любой класс, который понятия не имеет про GUI, к примеру, доступ к перекомпиляции которого вы не имеете, а вот активная модель обязана выполнять контракт издателя — вы не можете просто так взять класс и использовать его как активную модель, придется его научить немного.

Посыпаю голову пеплом, я не правильно понимал пассивную модель. Но в таком случае её нечего и рассматривать... )
Всё же 'предоставить возможность' подписаться кому-то, отлично коррелирует со слабой связностью...

C>>Если вью изменилось, модель измениться, а ну как бизнес-логика изменит какой-нить стейт в модели. Уверенности, что не забудут про рефреш вьюшки нету... а ну как несколько вьюшек, а некоторым и не интересно это изменение. Вообщем мне просто не нравится, что придумывают что-то на пустом месте...
R>Что здесь есть здесь "бизнес-логика", пример можно?

Имхо и так понятно, что в обоих случаях обеспечить можно. Просто, имхо, надёжней, при изменении модели, что-то предпринимать в обработчике события, чем ждать, что контроллер вызовет некоторый метод интерфейса моей вьюшки...

R> Все равно непонятно. Во-первых, чем таблица Excel не представление? Во-вторых, если таблица отображает список сотрудников, то модель — это Employee, а, к примеру, столбец этой таблицы EmployeeNameColumn — представление, отображающее модель Employee
R>в виде ячейки таблицы с текстом, значение которого берется из Employee.Name. EmployeeSurnameColumn — другое представление, отображающее тот же тип модели — Employee, просто в другом виде. И т.п. Не вижу, с чего вдруг модели быть оберткой над столбцами, она ж не знает о GUI ничего.

Ну, конечно, не знает. Я имел ввиду, без всяких Employee-ров, юзер вбивает столбец из 20 чисел, потом обводит мышой 5 из них... моделью будет, допустим, некоторая обёртка над внутренним представлением (5-ый столбец, с 5-ой по 10-ую строчку — это во внутреннем представлении, а не в гуи). Потом юзер строит 3 диаграммы. Такс, а к чему мы это... а... к тому, что диаграмма может обработывать любую модель с тем же интерфейсов. Ацтойный пример, можете не коментировать...

C>>Нет я не о выделении, конечно... ну видимо плохой пример...
R>Дайте хороший.

Я вот тоже просил... за мной будете...

P.S. Если можно, не нужно 'вы'...
"Не морочьте мне голову. Полыхаев" ©
Re[18]: Model-View-Controller в .Net
От: IB Австрия http://rsdn.ru
Дата: 05.05.08 08:14
Оценка: 10 (3) +1
Здравствуйте, chocho, Вы писали:

C>Имхо и так понятно, что в обоих случаях обеспечить можно. Просто, имхо, надёжней, при изменении модели, что-то предпринимать в обработчике события, чем ждать, что контроллер вызовет некоторый метод интерфейса моей вьюшки...


Так, давай с начала...
Классический MVC с активным View: Контроллер совсем дохлый, по большей части служит pass-thru слоем. Модель декларирует события, View на них подписывается и при изменении сама себя обновляет, вытаскивая нужные данные из модели.
1. Плохая тестируемость View. То есть, View тестировать полюбому застрелишься, но в данном случае во View оказывается часть логики вытаскивания данных и распихивания по контролам которую как раз и не плохо было бы потестировать.
2. View знает о конкретной модели, появляется лишняя связь, что приводит к тому, что переиспользовать View с другой моделью будет затруднительно.
3. Тот факт, что часть логики вынесена во View (см. пункт один) сам по себе не очень хорош.
Выход простой — делаем View пассивным, то есть не вью забирает данные из модели, а данные подпихиваются во вью контроллером.
1. Появилась возможность протестировать логику загрузки данных из модели во вью — она теперь ни как не связана с UI-ем и значит легко поддается тестированию.
2. В общем случае, то что во View подпихивает контроллер может отличаться от оригинальной модели, значит View о конкретной модели не знает ничего и может быть совершенно безболезненно переиспользован в другом месте с другой моделью.
Таким образом мы получили MVP/MVC с Passive View и по ходу поняли ради чего мы это делаем.
При этом заметь, я нигде не трогал модель — она по прежнему выставляет события наружу и ждет что кто-то на них подпишется.. При этом кто конкретно — ей пофиг, может контроллер, а может View.

Теперь, что у нас не так в этой схеме с моделью? С тестированием проблем нет, но есть проблемы с событиями.
1. Их надо выбросить. Модель может меняться произвольным образом, на каждое изменение делать отдельное событие — может оказаться утомительным.
2. В сложных случаях событие надо выбрасывать не при каждом изменении, а по сложному условию — как следствие, в модель переползает часть бизнес-логики, что совсем уже плохо.
3. на событие можно банально забыть подписаться и не обработать, в этом случае для устранения проблемы придется лезть и в контроллер и в модель. Вообще, линейный код всяко проще, чем код на событиях — и для написания и для сопровождения.
Выход опять-таки очевиден — контроллеру, вместо того чтобы подписавшись на модель ждать от нее события что она там что-то у себя поменяла, после чего лезть опять в модель, забирать измененные данные и пихать их во вью, проще самому выступить инициатором всех действий: поменял модель, перечитал данные модели (если нужно), обновил вью.
Иными словами, поскольку де факто, источником изменений в любом случае является контроллер, то проще и надежнее его самого нагрузить логикой разруливания сценариев отображения.
Вот мы и получили MVP, где Presenter в отличии от контроллера, уже является довольно жирным куском кода.

Чего добились?
1. Вся логика отображения в одном месте, а не размазана по вьюшкам и, в худшем случае, моделям. А зачастую, в некоторых типах приложений это по сути бизнес-логика.
2. Вся эта логика хорошо тестируется.
3. Она проще, так как линейна и основана не на событиях.
... << RSDN@Home 1.2.0 alpha rev. 673>>
Мы уже победили, просто это еще не так заметно...
Re[19]: Model-View-Controller в .Net
От: Aikin Беларусь kavaleu.ru
Дата: 05.05.08 10:39
Оценка:
Спасибо, очень доходчиво.

Есть несколько вопросов:
IB>2. View знает о конкретной модели, появляется лишняя связь, что приводит к тому, что переиспользовать View с другой моделью будет затруднительно.
Как-то не могу сказать что это плохо. Лично я затрудняюсь привести пример View которую можно расшарить между несколькими моделями.
Возьмем Employer и Employee.
Если их рассматривать как Person (предок обоих), то можно сделать PersonView которой все равно кого ей передали.
Если же как отдельные сущности, то, ИМХО, мы либо не сможем создать шареную вью для обоих, либо это нам обойдется очень дорого, ИМХО, даже дороже поддержки двух параллельных вью.
И это на примере родственных объектов. Что же говорить про более далекие?

С другой стороны мне импонирует идея Вью как "трафарета с дырками" куда можно расставить "все что угодно", единственное интерфейс этой Вью будет перенасыщен:
public IView
{
    Employee Employee;
}
// против
public IView
{
    String FirstName;
    String LastName;
    // ...
    String EmployerName; // уже завязка на employee
    // ...
}


В первом подходе есть еще одна потенциальная дыра: через 5 лет, 10-й саппортер нашего приложения не слышавший о MVP вызовет метод бизнесс логики класса Employee внутри Вью. Но это уже паранойя.

Еще раз спасибо, Aikin.
... << RSDN@Home 1.2.0 alpha 4 rev. 1067>>
Re[20]: Model-View-Controller в .Net
От: rsn81 Россия http://rsn81.wordpress.com
Дата: 05.05.08 11:22
Оценка: 2 (1)
Здравствуйте, Aikin, Вы писали:

A>Как-то не могу сказать что это плохо. Лично я затрудняюсь привести пример View которую можно расшарить между несколькими моделями.

A>Возьмем Employer и Employee.
Не, возьмем пример проще, представление отображающее строку текста в виде метки:
class LabelView {
    private Label label;
  
    public void setText(String text) {
        label.setText(text);
    }
}
LabelView и не знает, о том, что ее могут использовать как для отображения Employee.getName, так и для Employer.getName.

A>Если их рассматривать как Person (предок обоих), то можно сделать PersonView которой все равно кого ей передали.

Можно и так, но проще все же делать сложные представления в виде композиции простых однотипных постоянно переиспользуемых везде представлений.

A>Если же как отдельные сущности, то, ИМХО, мы либо не сможем создать шареную вью для обоих, либо это нам обойдется очень дорого, ИМХО, даже дороже поддержки двух параллельных вью.

Можно, просто атомарность представлений снизьте, ну как в примере с LabelView.

A>И это на примере родственных объектов. Что же говорить про более далекие?

[skipped]
Представление вовсе не обязано отображать все свойства модели.
Re[21]: Model-View-Controller в .Net
От: Aikin Беларусь kavaleu.ru
Дата: 05.05.08 11:45
Оценка:
R>Не, возьмем пример проще, представление отображающее строку текста в виде метки:
Ага, до такого я как-то не додумался Но будет ли удобно работать с большим количеством маленьких вьюшек?
Хотя где-то я уже читал про микровью и микроконтролееры (кажется один именитый архитектор ими просто бредил), отзывы о них были как-то не особо положительные.

A>>Если их рассматривать как Person (предок обоих), то можно сделать PersonView которой все равно кого ей передали.

R>Можно и так, но проще все же делать сложные представления в виде композиции простых однотипных постоянно переиспользуемых везде представлений.
Можно поинтересоваться, ты сам использовал такой подход? Каковы впечателения от использования?

A>>И это на примере родственных объектов. Что же говорить про более далекие?

R>[skipped]
R>Представление вовсе не обязано отображать все свойства модели.
Я эт знаю
... << RSDN@Home 1.2.0 alpha 4 rev. 1067>>
Re[19]: Model-View-Controller в .Net
От: chocho Россия  
Дата: 05.05.08 12:08
Оценка:
Здравствуйте, IB, Вы писали:

IB>Чего добились?
IB>1. Вся логика отображения в одном месте, а не размазана по вьюшкам и, в худшем случае, моделям. А зачастую, в некоторых типах приложений это по сути бизнес-логика.
IB>2. Вся эта логика хорошо тестируется.
IB>3. Она проще, так как линейна и основана не на событиях.

Ну может быть и не так плоха эта модель... )

Пока остались только следующие соображения:
1) Порой не так уж плохо доверить вью отображать так ей нада. Может быть и жертвуем тестирабельностью, но так чётко разграничены полномочия. Вью отображает изменения, а контроллер отвечает за действия пользователя (таймера и т.п.). Универсальность — плохо, масштабируемость — хорошо. А тут, контроллер не зная ничего о своих вью, должен универсальным образом говорить им что обновилось.
2)Второй поинт в том, что в сложных задачах этих триад несколько. Они связаны по контроллерам. Если контроллеры ещё и держат ссылки на вью, да этих вью несколько, как бы не смешалось всё... Тут нужен опыт подобной разработки, без него мне сложно судить....
"Не морочьте мне голову. Полыхаев" ©
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.