Model-View
От: Gadsky Россия  
Дата: 19.08.07 16:19
Оценка:
Как часто вам приходилось работать с такой моделью?
View — не оповещается Моделью, но в Idle периоды опрашивает его насчет изменения состояния.
В результате Model развязано с View даже на уровне интерфейса, но каковы основные минусы?
Re: Model-View
От: IB Австрия http://rsdn.ru
Дата: 19.08.07 20:05
Оценка:
Здравствуйте, Gadsky, Вы писали:

G>View — не оповещается Моделью, но в Idle периоды опрашивает его насчет изменения состояния.

G>В результате Model развязано с View даже на уровне интерфейса, но каковы основные минусы?
Зависимость от Idle состояния или от таймера, довольно задумчивый View может получиться... Собственно, зачем на это завязываться, когда все изменения все равно попадают в систему через Controller/Presenter и он, как правило, обладает полной информацией о том, какой View нуждается в этих самых новых данных — вот пусть и дает View команду на обновление... Собственно так и устроен MVP с пассивным View.
Мы уже победили, просто это еще не так заметно...
Re: Model-View
От: iZEN СССР  
Дата: 19.08.07 22:24
Оценка:
Здравствуйте, Gadsky, Вы писали:

G>Как часто вам приходилось работать с такой моделью?

G>View — не оповещается Моделью, но в Idle периоды опрашивает его насчет изменения состояния.
G>В результате Model развязано с View даже на уровне интерфейса, но каковы основные минусы?

Фиксированный FPS можно так получить. А это значит, что может найти применение в системах реального времени.
Re: Model-View
От: FlevelEx Россия  
Дата: 20.08.07 01:20
Оценка:
Здравствуйте, Gadsky, Вы писали:

G>Как часто вам приходилось работать с такой моделью?

G>View — не оповещается Моделью, но в Idle периоды опрашивает его насчет изменения состояния.
G>В результате Model развязано с View даже на уровне интерфейса, но каковы основные минусы?


если под Model подразумевать чисто Domain Model,
то в Model/View — "контроллер" переходит во View и получаем такие вещи как:
Microsoft Document/View, Swing Model/Delegation
и соответствующие минусы:
замена view с дублирования логики "контроллера", хранение состояния view, не-testable UI итд


другой вариант, если Model это Domain Model + некоторая промежуточная модель, которая берёт на себя решение вышеперечисленных проблем и является специфичной моделью для конкретного View + выполняет часть функций "контроллера"

ключевые слова:
Presentation Model (Фаулер)
Application Model (SmallTalker-ы)
Model/View/ViewModel (WPF team)

тут к минусам можно отнести, например, сложность для небольших приложений, дублирование реальной модели, невозможность прямого доступа к виду (как в MVP)
 
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.