Тот самый MVC для desktop

Доброго времени, форумчане. Последнее время пытаюсь постигнуть дзен пониманием паттернов программирования GUI-приложений, но в голове мозаика не складывается. Хорошей литературы достаточно для веб, но MVC для веб не увязывается с настольными приложениями. Да и стоит ли, может тут лучше использовать другой подход?

Сейчас я понимаю View как набор состояний отображения, Controller переключает эти состояния, и Model хранит логику программы и методы для её изменения. Закрадывается предположение,что модели для View и Controller - разные понятия. Эти все теории просты, когда эта троица представлена в одном экземпляре, но когда появляется дерево моделей, вложенные вьюшки, в том числе для повторного использования, контролер или раздувается до деградации ООП к простым функциям (методам внутри одного контролера), или теряет переносимость при изменении структуры моделей или представления, так вот тогда становится непонятно, кто кого имеет, что во что вложено, кто какие выполняет задачи.

Пишу на Qt c++, там есть сигналы и подписка на них. Но мне бы хотелось обсудить сам принцип, можно на общих схемах.

0

Сообщение от O_Q но когда появляется дерево моделей,

это вьюшек может быть множество.
а модель должна быть одна.

суть вьюшек: по разному показывать одну и туже модель.
при изменении модели, вьюшки идут лесом,
и приходится пилить новые.

0

O_Q, начинается всё всегда с модели. Модель состоит из данных, методов доступа к ним и методов изменения данных. Controller и View не содержат данных (кроме служебных).
View занимается только отображением интерфейса: он отображает данные, обращаясь к Model и показывает пользователю элементы управления (кнопочки, поля редактирования, меню и др.).
Controller - необязательный компонент. Он управляет реакцией на события. События бывают двух типов - зависящие от действий пользователя (тогда View вызывает методы Controller-а) и независимые (например, таймеры могут быть встроены в Controller).

0

Сообщение от hoggy это вьюшек может быть множество. а модель должна быть одна.

Как же она может быть одна? Возьмём стандартный пример: у нас есть класс "книга" и "покупатель", 2 класса - 2 модели. Если мы возьмём динамический интерфейс, тогда у нас появляются виджеты с отображением моделек, каждый из которых работает с отдельным объектом.

0

O_Q
Одна модель -- один MVC. Если две модели, то два MVC. Книга и покупатель -- это какие-то бизнес-объекты, которые, скорее являются частью программной модели какого-то бизнес-процесса.

0

Сообщение от O_Q Как же она может быть одна? Возьмём стандартный пример: у нас есть класс "книга" и "покупатель", 2 класса - 2 модели.

это два класса какой то одной модели.

модель определяется совокупностью классов,
которые определяют её бизнес-логику.

0

"Модель" употребляется в разных значениях. Модель, которая "М" в MVC - это доменная модель, то есть, совокупность классов, которые определяют бизнес-логику.

0

Сообщение от Shamil1 Модель, которая "М" в MVC - это доменная модель

Разве? Она может быть доменной моделью (если повезёт), но, как правило, является частью триады MVC, т.е. частью уровня представления.

0

Сообщение от Usaga частью уровня представления

MVC как раз и придумано, чтобы модель бизнес-процесса отделить от представления. М -- не является "частью уровня представления". V -- есть уровень представления, а M -- уровень процесса, который спрятан, инкапсулирован, от клиента (будь это пользователь или другая программа) посредством макета процесса, выраженного потоками ввода C и вывода V.

0

mporro, к уровню представления я отношу всю триаду MVC (представление != уровень представления), точнее все такие наборы (окна/страницы). View (представление) - это уже часть этого уровня. Модель триады MVC (или MVP) так же является частью уровня представления, так как отражает фунцкиональность данного окошка/страницы. Если для этой цели можно использовать модель предметной области без переделок, то зашибись - не нужно будет делать 100500 моделей .

Но у окошка может быть функционал не являющий частью бизнес-процесса, но являющий исключительно частью UI (выбранный элемент списка, имя файла выбранного документа, логин/пароль на странице авторизации). Вот это и должно храниться в модели MVC. Вообще, как мне кажется, иметь на каждом уровне свой набор моделей - нормальное явление.

Вот и получается, что у бизнес-процессов свой набор моделей, у уровня представления свой (причём модели MVC могут содержать модели бизнес-уровня). Очень хорошо, если можно переиспользовать модели между уровнями, но так далеко не всегда может быть.

Добавлено через 6 минут
mporro, тут ещё надо не забывать, что чёткого описания MVC нету, каждый автор трактует всё по своему. Я вот, придерживаюсь варианта предложенного Дино Эспозито, мне его видение архитектуры ПО кажется разумным. Так, что это вопрос дискуссионного характера .

0

Добавлено через 23 минуты

0

mporro, значит я и правда мог что-то не так понять.

На данный момент я практикую такой подход: модель из MVC (MVP) - агрегат содержащий как модели предметной области так и примитивы необходимые представлению. Т.е. модель содержит только то, что нужно представлению и, возможно, в более удобном для него виде (а это уже может не быть доменная модель). Контроллер\презентер, реагируя на запрос от представления, обращается к моделям предметной области и, если нужно, к службам предметной области, а так же обновляет другие данные в модели MVC. После этого представление обновляется.

Это не верная трактовка?

0

Сообщение от Usaga Это не верная трактовка?

Я не супер-эксперт в MVC, но оригинальная идея подразумевает барьеры между элементами "тройки". Если Вы эти барьеры видите и можете вынимать то, что называете контроллером, и заменять его, то у Вас всё в порядке. Если же Вы при замене представления из GUI в XML вынуждены поковыряться в модели -- это яркая красная лампа, что MVC построено плохо.

P.S. Ещё сегодня развелось очень много дочерних подходов, которые борются с проблемой "виджетов", так как оригинальная идея становится через-чур многословной. Так как книга, которую Вы привели, что-то там про MS и .NET, то, возможно, там вообще не про MVC, а какой-то специальный подход для работы с системой "виджетов", которые гораздо сложнее, чем оригинальный Tool.

0

Я считаю:

MVC - это не набор троек M-V-C.
У меня одна Модель и несколько Контроллеров. На каждый из Контроллеров может быть несколько Представлений.

Сообщение от Usaga модель содержит только то, что нужно представлению и, возможно, в более удобном для него виде

Рассмотрим веб-приложение.
Для работы с одним Представлением Контроллер использует разные виды классов:
1. "формы" - классы для получения данных от Представления
2. "модель представления" - классы для передачи данных представлению
3. "службы" - классы для изменения Модели (Предметной Модели) и получения данных из Модели (бизнес-логика)

Но я не считаю, что "формы" или "модели представления" играют роль модели в MVC.

0

Сообщение от mporro Если Вы эти барьеры видите и можете вынимать то, что называете контроллером, и заменять его, то у Вас всё в порядке.

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

Книжка действительно не про MVC, но про модели как таковые. Я оттуда много чего подчерпнул. Хотя специалисты там вряд ли что-то новое найдут.

Добавлено через 5 минут

Сообщение от Shamil1 Но я не считаю, что "формы" или "модели представления" играют роль модели в MVC.

Ну я тоже так не считаю. В данном случае это просто DTO. Тоже самое можно было бы сделать и в "настольном" MVC, упаковывая данные для передачи контроллеру.

0

Сообщение от Usaga В данном случае это просто DTO.

Я бы не стал называть это DTO.
Класс формы содержит поля, которые есть на форме (включая скрытые). И эти поля могут содержать служебную информацию или информацию, необходимую лишь для валидации.
Класс модели представления содержит информацию, необходимую представлению. И эта информация может быть собрана из разных источников.

0