Не, на MVC мой подход точно не тянет. Это в лучшем случае MVVM - Model, View, View model. На самом деле еще хуже - MMMV. Model, model, model, ... View. Количество моделей произвольное и даже в одном интерфейсе между входной моделью и разными вью промежуточных слоев может быть разное количество. Контроллеров нет совсем, есть трансформеры моделей.
Цитата:
|
Ну поидее потому, что кнопка не должна решать, что произойдет когда ее нажмут, а вот контроллер как раз должен об этом заботится.
|
То, что не одна должна заботиться - это правильно. Но вопрос в том, должно ли UI кнопки, например, иметь параметры "enabled/disabled" или нет. Если может, нужно писать контроллер, который в нужные моменты свойства выставляет и т.п. Или можно его внести в модель действия для кнопки. В этом случае получается View model - модель для view в терминах view. Отсюда и разница. Можно жестко прикрутить Controller к UI и там разбираться, что и где было нажато. А можно создать действие и для него нарисовать "абстрактный UI".
@TanaTIX:
Цитата:
|
эту панель скрыть, а эту показать, а вон ту - ее на задний план.
|
И потом начинаются баги. В случае каких-то переходов какие-то панели могут быть не показаны, другие лишний раз показаны и т.п. Просто забыто будет. Для сложных UI вполне возможно. Альтернативный вариант - модель "активная страница приложения". К ней привязка различных компонент. Можно отдельно модели видимости панелей сделать - VisibleInState, например. И т.п. В качестве бонуса получаем, что в результате если какая-то страница сверстана правильно, она и будет сверстана правильно вне зависимости, откуда и как на нее попали.