Здравствуйте.

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

thanks написав(ла):
> У меня следующая ситуация:
> Контроллер подписан на события модели об изменении оной. Вид вызывает
> контроллер при изменении, допустим, ItemIndex в комбобоксе. При этом
> контроллер меняет модель и, получая оповещение об изменении модели,
> обращается к виду с тем, что бы тот поменял ItemIndex у комбобокса.

Это вы обычный биндинг описали или свой велосипед изобрели?

> Вроде логично, но как-то неправильно, зачем получать оповещение, если
> это я же и поменял.

Все более чем логично. Вид только пытается изменить модель через
контроллер. Логика модели может, например, не принять значение и
выбросить Exception.

> Подскажите, пожалуйста, как лучше разрулить данную ситуацию.

Не разруливать ее? Ибо все правильно и логично.

Здравствуйте, Ромашка, Вы писали:

Р>Это вы обычный биндинг описали или свой велосипед изобрели?
пока что свой велосипед

Р>Все более чем логично. Вид только пытается изменить модель через
Р>контроллер. Логика модели может, например, не принять значение и
Р>выбросить Exception.
А если взять, например, RichTextBox. В него юзер ввёл 5 КБ текста, этот текст в итоге попадает в модель, вызывает её изменение и эти же 5 КБ текста приходят обратно в вид.
Тут получается что лишний трафик бегает + состояние RichTextBox (текущее выделение, позиция курсора) сбросится из-за того, что снова задали этот же текст

А как быть с случаем когда логика не приняла текст и нужно сбросить текст на старый.
У меня получается, что все эти телодвижения вызывают повторные вызовы изменения модели и вида (вид-контроллер-модель-контроллер-вид-контроллер-модель)

thanks написав(ла):
> А если взять, например, RichTextBox. В него юзер ввёл 5 КБ текста, этот
> текст в итоге попадает в модель, вызывает её изменение и эти же 5 КБ
> текста приходят обратно в вид.

На самом деле, пример с RichTextBox еще более показательный, ибо даже
если изменения текста приняты, не факт, что приняты в полном объеме или
в таком же виде. Например, заменены кавычки на " в вебе, вырезаны
инструкции "drop database" или еще какая-нибудь фигня.

> Тут получается что лишний трафик бегает + состояние RichTextBox (текущее
> выделение, позиция курсора) сбросится из-за того, что снова задали этот
> же текст

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

> А как быть с случаем когда логика не приняла текст и нужно сбросить
> текст на старый.

Считать текст свойства? Только так, даже если модель приняла текст. По
хорошему, изменение одного свойства в виде не подразумевает того, что в
модели изменится только одно свойство. Например, при изменении цены в
строке должна измениться сумма документа, при изменении текста должна
стать доступной кнопка сохранения и т.д. и т.п. Поэтому приблизительно так:
Изменяется что-то в виде. Контроллер получает событие, меняет что-то в
модели. Модель изменяет свое свойство (или несколько), выбрасывает
несколько событий контроллеру. Контроллер по каждому из событий
считывает свойство модели и присваивает его виду.

> У меня получается, что все эти телодвижения вызывают повторные вызовы
> изменения модели и вида
> (вид-контроллер-модель-контроллер-вид-контроллер-модель)

Это нормально. По другому, в общем случае, и не получится.

Здравствуйте, thanks

Для MVC это нормально, но если это вызывает большие накладные расходы то нужно добавить проверку либо в метод изменения модели об источнике изменившем модель, либо во View добавить equals() для контролла ...

Здравствуйте, Ромашка, Вы писали:

Р>Это нормально. По другому, в общем случае, и не получится.
Спасибо за разъяснение.
А есть какие-нибудь источники на тему MVC где бы рассказывалось про "проблемы использования".
Например, с этим вопросом я ковыряюсь несколько дней, думаю как получше сделать (благо время позволяет), а оказывается и так нормально.

thanks написав(ла):
> А есть какие-нибудь источники на тему MVC где бы рассказывалось про
> "проблемы использования".

Это не ко мне — я ненавижу паттерны вообще и MVC в частности.

ЗЫ. Кстати, вам тоже спасибо — благодаря вам я понял, за что я их
ненавижу. За то, что отбивают у программиста желание думать в
терминах абстракции (модели) и заставляют думать в терминах паттерна.

Здравствуйте, Ромашка, Вы писали:

Р>Это не ко мне — я ненавижу паттерны вообще и MVC в частности.

Имхо ненавидеть их не надо. Просто часто паттерны навязываются людям даже тогда, когда они им не нужны. Вот это неправильно.

MozgC написав(ла):
> Р>Это не ко мне — я ненавижу паттерны вообще и MVC в частности.
>
> Имхо ненавидеть их не надо. Просто часто паттерны навязываются людям
> даже тогда, когда они им не нужны. Вот это неправильно.

Паша, люди просто живут паттернами. Это нормально, это не повод
ненавидеть свою жизнь. Речь идет именно о введенном бандой четырех
понятии — паттерн программирования. Вне зависимости от нужен паттерн или
нет, невозможно описать решение терминами паттерна. Это, вообще говоря,
первый принцип сложных систем — система может быть описана только в
терминах суперсистемы. Несоблюдение этого простого принципа приводит к
убожествам вроде LineController вместо банального Brush, которые меня
тупо бесят.

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

T>Вроде логично, но как-то неправильно, зачем получать оповещение, если это я же и поменял.
Ну, из всего этого, логичен только этот вопрос.
В классическом MVC все выглядит немного по другому. Там непосредственно View получает оповещение от модели о том, что она изменилась, а вовсе не контроллер.
Такое поведение обладает рядом недостатков, в частности, наличием у View довольно серьезной логики и тем, что View обладает знаниями о модели, а также, лишними раундтрипами данных между моделью и другими слоями... Альтернативой является паттерн MVP (Model-View-Presenter). В терминологии Фаулера это больше всего похоже на Passive View. В этом случае наоборот, все проходит через контроллер(презентер), но уже безо всяких событий за их очевидной ненадобностью.
Событие об изменении прилетает в презентер, тот сначала меняет модель, а затем самостоятельно меняет нужный набор представлений, без лишних приседаний вокруг модели, поскольку и так знает, что нужно менять.

T>Подскажите, пожалуйста, как лучше разрулить данную ситуацию.
Тут сильно зависит от задачи.

Здравствуйте, Ромашка, Вы писали:

Р>Это нормально. По другому, в общем случае, и не получится.
В общем случае, только по другому и получается..