-7 / 2 / 1
Регистрация: 10.04.2016
Сообщений: 53
|
|
1 | |
Тот самый MVC для desktop13.05.2016, 17:21. Показов 2762. Ответов 15
Метки нет (Все метки)
Доброго времени, форумчане. Последнее время пытаюсь постигнуть дзен пониманием паттернов программирования GUI-приложений, но в голове мозаика не складывается. Хорошей литературы достаточно для веб, но MVC для веб не увязывается с настольными приложениями. Да и стоит ли, может тут лучше использовать другой подход?
Сейчас я понимаю View как набор состояний отображения, Controller переключает эти состояния, и Model хранит логику программы и методы для её изменения. Закрадывается предположение,что модели для View и Controller - разные понятия. Эти все теории просты, когда эта троица представлена в одном экземпляре, но когда появляется дерево моделей, вложенные вьюшки, в том числе для повторного использования, контролер или раздувается до деградации ООП к простым функциям (методам внутри одного контролера), или теряет переносимость при изменении структуры моделей или представления, так вот тогда становится непонятно, кто кого имеет, что во что вложено, кто какие выполняет задачи. Пишу на Qt c++, там есть сигналы и подписка на них. Но мне бы хотелось обсудить сам принцип, можно на общих схемах.
0
|
13.05.2016, 17:21 | |
Ответы с готовыми решениями:
15
Тот самый DateTimePicker Тот же самый отбор r6010 - Abort() (тот самый Страуструпп) Реализация MVC паттерна в несложном desktop приложение на Java |
8739 / 4317 / 960
Регистрация: 15.11.2014
Сообщений: 9,760
|
|
16.05.2016, 19:48 | 2 |
это вьюшек может быть множество.
а модель должна быть одна. суть вьюшек: по разному показывать одну и туже модель. при изменении модели, вьюшки идут лесом, и приходится пилить новые.
0
|
44 / 44 / 19
Регистрация: 04.05.2014
Сообщений: 190
|
|
18.05.2016, 10:54 | 3 |
O_Q, начинается всё всегда с модели. Модель состоит из данных, методов доступа к ним и методов изменения данных. Controller и View не содержат данных (кроме служебных).
View занимается только отображением интерфейса: он отображает данные, обращаясь к Model и показывает пользователю элементы управления (кнопочки, поля редактирования, меню и др.). Controller - необязательный компонент. Он управляет реакцией на события. События бывают двух типов - зависящие от действий пользователя (тогда View вызывает методы Controller-а) и независимые (например, таймеры могут быть встроены в Controller).
0
|
-7 / 2 / 1
Регистрация: 10.04.2016
Сообщений: 53
|
|
22.05.2016, 18:16 [ТС] | 4 |
Как же она может быть одна? Возьмём стандартный пример: у нас есть класс "книга" и "покупатель", 2 класса - 2 модели. Если мы возьмём динамический интерфейс, тогда у нас появляются виджеты с отображением моделек, каждый из которых работает с отдельным объектом.
0
|
306 / 101 / 18
Регистрация: 04.07.2014
Сообщений: 571
|
|
22.05.2016, 18:41 | 5 |
O_Q
Одна модель -- один MVC. Если две модели, то два MVC. Книга и покупатель -- это какие-то бизнес-объекты, которые, скорее являются частью программной модели какого-то бизнес-процесса.
0
|
8739 / 4317 / 960
Регистрация: 15.11.2014
Сообщений: 9,760
|
|
22.05.2016, 21:11 | 6 |
это два класса какой то одной модели.
модель определяется совокупностью классов, которые определяют её бизнес-логику.
0
|
Модератор
3051 / 2193 / 459
Регистрация: 26.03.2015
Сообщений: 8,469
|
|
22.05.2016, 23:20 | 7 |
"Модель" употребляется в разных значениях. Модель, которая "М" в MVC - это доменная модель, то есть, совокупность классов, которые определяют бизнес-логику.
0
|
12078 / 8387 / 1281
Регистрация: 21.01.2016
Сообщений: 31,595
|
|
23.05.2016, 08:51 | 8 |
Разве? Она может быть доменной моделью (если повезёт), но, как правило, является частью триады MVC, т.е. частью уровня представления.
0
|
306 / 101 / 18
Регистрация: 04.07.2014
Сообщений: 571
|
|
23.05.2016, 09:29 | 9 |
MVC как раз и придумано, чтобы модель бизнес-процесса отделить от представления. М -- не является "частью уровня представления". V -- есть уровень представления, а M -- уровень процесса, который спрятан, инкапсулирован, от клиента (будь это пользователь или другая программа) посредством макета процесса, выраженного потоками ввода C и вывода V.
0
|
12078 / 8387 / 1281
Регистрация: 21.01.2016
Сообщений: 31,595
|
|
23.05.2016, 11:28 | 10 |
mporro, к уровню представления я отношу всю триаду MVC (представление != уровень представления), точнее все такие наборы (окна/страницы). View (представление) - это уже часть этого уровня. Модель триады MVC (или MVP) так же является частью уровня представления, так как отражает фунцкиональность данного окошка/страницы. Если для этой цели можно использовать модель предметной области без переделок, то зашибись - не нужно будет делать 100500 моделей .
Но у окошка может быть функционал не являющий частью бизнес-процесса, но являющий исключительно частью UI (выбранный элемент списка, имя файла выбранного документа, логин/пароль на странице авторизации). Вот это и должно храниться в модели MVC. Вообще, как мне кажется, иметь на каждом уровне свой набор моделей - нормальное явление. Вот и получается, что у бизнес-процессов свой набор моделей, у уровня представления свой (причём модели MVC могут содержать модели бизнес-уровня). Очень хорошо, если можно переиспользовать модели между уровнями, но так далеко не всегда может быть. Добавлено через 6 минут mporro, тут ещё надо не забывать, что чёткого описания MVC нету, каждый автор трактует всё по своему. Я вот, придерживаюсь варианта предложенного Дино Эспозито, мне его видение архитектуры ПО кажется разумным. Так, что это вопрос дискуссионного характера .
0
|
306 / 101 / 18
Регистрация: 04.07.2014
Сообщений: 571
|
|
23.05.2016, 13:01 | 11 |
Не по теме: И тем самым просто уничтожаете саму идею MVC. Чтобы MVC идея работала, видеть слои M V C необходимо отдельно. Если Вы не видите этих слоёв и вам кажется, что есть какая-то особая M, которая связана особыми отношениями с "представлением", значит где-то дырка в вашем MVC. Уничтожение идеи -- это не трактовка, а именно уничтожение. Добавлено через 23 минуты Не по теме: Я, к сожалению, с этим трудом не знаком. Но почти уверен, что Вы что-то не так поняли. Это случается, часто. Скорее всего, речь шла о том, что само представление может иметь свою логику, выраженную каким-то, скажем, конечным автоматом, который и является модель интерфейса. В таком случае автомат является частью буквы V, а M как была доменная модель так и осталась.
0
|
12078 / 8387 / 1281
Регистрация: 21.01.2016
Сообщений: 31,595
|
|
23.05.2016, 16:07 | 12 |
mporro, значит я и правда мог что-то не так понять.
На данный момент я практикую такой подход: модель из MVC (MVP) - агрегат содержащий как модели предметной области так и примитивы необходимые представлению. Т.е. модель содержит только то, что нужно представлению и, возможно, в более удобном для него виде (а это уже может не быть доменная модель). Контроллер\презентер, реагируя на запрос от представления, обращается к моделям предметной области и, если нужно, к службам предметной области, а так же обновляет другие данные в модели MVC. После этого представление обновляется. Это не верная трактовка?
0
|
306 / 101 / 18
Регистрация: 04.07.2014
Сообщений: 571
|
|
23.05.2016, 16:30 | 13 |
Я не супер-эксперт в MVC, но оригинальная идея подразумевает барьеры между элементами "тройки". Если Вы эти барьеры видите и можете вынимать то, что называете контроллером, и заменять его, то у Вас всё в порядке. Если же Вы при замене представления из GUI в XML вынуждены поковыряться в модели -- это яркая красная лампа, что MVC построено плохо.
P.S. Ещё сегодня развелось очень много дочерних подходов, которые борются с проблемой "виджетов", так как оригинальная идея становится через-чур многословной. Так как книга, которую Вы привели, что-то там про MS и .NET, то, возможно, там вообще не про MVC, а какой-то специальный подход для работы с системой "виджетов", которые гораздо сложнее, чем оригинальный Tool.
0
|
Модератор
3051 / 2193 / 459
Регистрация: 26.03.2015
Сообщений: 8,469
|
|
23.05.2016, 17:50 | 14 |
Я считаю:
MVC - это не набор троек M-V-C. У меня одна Модель и несколько Контроллеров. На каждый из Контроллеров может быть несколько Представлений. Рассмотрим веб-приложение. Для работы с одним Представлением Контроллер использует разные виды классов: 1. "формы" - классы для получения данных от Представления 2. "модель представления" - классы для передачи данных представлению 3. "службы" - классы для изменения Модели (Предметной Модели) и получения данных из Модели (бизнес-логика) Но я не считаю, что "формы" или "модели представления" играют роль модели в MVC.
0
|
12078 / 8387 / 1281
Регистрация: 21.01.2016
Сообщений: 31,595
|
|
23.05.2016, 18:02 | 15 |
Да, именно из-за этого я и использую этот паттерн (а иначе нафига оно надо? ). Просто у меня возникли сомнения, что я не правильно роль модели себе представляю. Возможно, что это действительно так. Но разделение (и тестопригодность) кода это не влияет, а значит всё путём.
Книжка действительно не про MVC, но про модели как таковые. Я оттуда много чего подчерпнул. Хотя специалисты там вряд ли что-то новое найдут. Добавлено через 5 минут Ну я тоже так не считаю. В данном случае это просто DTO. Тоже самое можно было бы сделать и в "настольном" MVC, упаковывая данные для передачи контроллеру.
0
|
Модератор
3051 / 2193 / 459
Регистрация: 26.03.2015
Сообщений: 8,469
|
|
23.05.2016, 22:11 | 16 |
Я бы не стал называть это DTO.
Класс формы содержит поля, которые есть на форме (включая скрытые). И эти поля могут содержать служебную информацию или информацию, необходимую лишь для валидации. Класс модели представления содержит информацию, необходимую представлению. И эта информация может быть собрана из разных источников.
0
|
23.05.2016, 22:11 | |
23.05.2016, 22:11 | |
Помогаю со студенческими работами здесь
16
Не срабатывают события, если использовать тот же самый элемент в шаблоне кто зделает тот самый крутой на етом сайте(на языке с++) Почему в функцию можно передавать аргументы с амперсандом или без него и результат тот же самый? Самый самый тихий кулер для процессора Искать еще темы с ответами Или воспользуйтесь поиском по форуму: |