Здравствуйте. Возникли следущие вопросы по MVC.

1. Есть объект типа "набор объектов", что хранить у него в Model? Model'ы объектов, или их контроллеры.

2. Где надо хранить функции работы с моделью? Функции типа: добавить в набор еще один объект, удалить из набора объект, etc. Если в контроллере, то как быть с private данными Model'и, а если еще и в Model'е то, ИМХО, переусложнение.

Спасибо.

Здравствуйте, <Аноним>, Вы писали:

А>Здравствуйте. Возникли следущие вопросы по MVC.

А>1. Есть объект типа "набор объектов", что хранить у него в Model? Model'ы объектов, или их контроллеры.

А>2. Где надо хранить функции работы с моделью? Функции типа: добавить в набор еще один объект, удалить из набора объект, etc. Если в контроллере, то как быть с private данными Model'и, а если еще и в Model'е то, ИМХО, переусложнение.

Я понимаю так.

                  1 Модель 1
                 /          \
               оо            оо
        Контроллер 1<----->1 Вид

Модель:
 Фцнкция:       содержит Данные.
 Поля:          образно говоря, Массив обектов.
 Методы:        Добавить, Удалить, Найти (*)
 Особенность:   предоставляет (возможно, через Контроллер) Видам интерфейс для отлавливания событий изменений внутри себя.
                предоставляет (возможно, через Вид) Контроллерам интерфейс для изменения данных внутри себя.
 
Вид:
  Фцнкция:      Показывает в колонках свойства объектов, в строках - объекты.
  Поля:         ссылка на Модель, и, опять же, для примера, CurrencyManager к ней, который создаёт сама.
  Методы:       Выделить следующий, предыдущий, Удалить текущий, Войти в режим редактирования\добавления новой записи. (**)
  Особенность:  предоставляет Контроллеру интерфейс для отлавливания событий внутри себя и, возможно, доступ к Модели.
 
Контроллер:
  Фцнкция:      по событиям нажатия клавиатуры (DownArrow, LeftArrow, Ctrl+N) вызывает методы Вида (**) для навигации;
                по событиям нажатия клавиатуры (Enter, Esc) вызывает методы Модели для добавления\изменения данных (*)
  Поля:         ссылка на Модель и ссылка на Вид.

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

_FR>Я понимаю так.
_FR>

_FR>                  1 Модель 1
_FR>                 /          \
_FR>               оо            оо
_FR>        Контроллер 1<----->1 Вид

_FR>Модель:
_FR> Фцнкция:       содержит Данные.
_FR> Поля:          образно говоря, Массив обектов.
_FR> Методы:        Добавить, Удалить, Найти (*)
_FR> Особенность:   предоставляет (возможно, через Контроллер) Видам интерфейс для отлавливания событий изменений внутри себя.
_FR>                предоставляет (возможно, через Вид) Контроллерам интерфейс для изменения данных внутри себя.
 
_FR>Вид:
_FR>  Фцнкция:      Показывает в колонках свойства объектов, в строках - объекты.
_FR>  Поля:         ссылка на Модель, и, опять же, для примера, CurrencyManager к ней, который создаёт сама.
_FR>  Методы:       Выделить следующий, предыдущий, Удалить текущий, Войти в режим редактирования\добавления новой записи. (**)
_FR>  Особенность:  предоставляет Контроллеру интерфейс для отлавливания событий внутри себя и, возможно, доступ к Модели.
 
_FR>Контроллер:
_FR>  Фцнкция:      по событиям нажатия клавиатуры (DownArrow, LeftArrow, Ctrl+N) вызывает методы Вида (**) для навигации;
_FR>                по событиям нажатия клавиатуры (Enter, Esc) вызывает методы Модели для добавления\изменения данных (*)
_FR>  Поля:         ссылка на Модель и ссылка на Вид.
_FR>

На мой взгляд все несколько иначе: вид не должен имеет ссылку на модель, как вы указали, точно также модель ничего не должна знает о текущем виде. Модель и вид посылают сообщения друг другу только посредством интерфейса контроллера. Т.е. только интерфейс контроллера обеспечивает взаимодействие модели и вида. Таким образом, легко реализуется заменяемость видов и контроллеров.

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

_FR>>Я понимаю так.
_FR>>[pre]
_FR>> 1 Модель 1
_FR>> / \
_FR>> оо оо
_FR>> Контроллер 1<----->1 Вид

D>На мой взгляд все несколько иначе: вид не должен имеет ссылку на модель, как вы указали, точно также модель ничего не должна знает о текущем виде. Модель и вид посылают сообщения друг другу только посредством интерфейса контроллера. Т.е. только интерфейс контроллера обеспечивает взаимодействие модели и вида. Таким образом, легко реализуется заменяемость видов и контроллеров.

ОК, наверняка так оно и есть.
Тогда Контроллер должен иметь ссылку на данные из Модели, а Вид, в свою очередь, получает свою ссылку на данные через ссылку Контроллера?

Значит меня слегка сбила известная картинка (4К). Что означает стрелка от Вида к Модели? Получение сообщений об измении данных? Или что-то ещё?

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

_FR>Значит меня слегка сбила известная картинка (4К). Что означает стрелка от Вида к Модели? Получение сообщений об измении данных? Или что-то ещё?

На рисунке ниже в этой же статье Вид данные забирает напрямую из Модели...

Виду от модели нужны две вещи (как я вижу): данные и информация о том, что они поменялись. информацию Вид получает через события контроллера, а вот сами данные?

ДаЮ и, возможно, моя псевдографика вводит в заблуждение
Это:

                  1 Модель 1
                 /          \
               оо            оо
        Контроллер 1<----->1 Вид

связи-стрелки от модели _не означают_ что модель пораждает объекты Контоллера и Вида, а означают, что у одной и той же модели одновременно могут быть несколько N независимых друг от друга видов N независимых же друг отдура Контроллеров, но у каждого Контроллера один и только один Вид (или у каждого Вида один и только один Контроллер).

Пробовал я было иметь N Контроллеров и M > N Видов (то есть у одного Контроллера может быть несколько независимых друг от друга видов), но как-то слишком наворочено получилось Имеет такая идея право на существование?

Да вообще то ты был прав. Представление, естественно должено знать о модели — что бы извлекать из модели данные, если только ты не хочешь воспроизводить в контроллере интерфейс модели заного...

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

AF>Да вообще то ты был прав. Представление, естественно должено знать о модели — что бы извлекать из модели данные,

Практика покажет Надо посмотреть что ещё Виду может понадобится...

AF>если только ты не хочешь воспроизводить в контроллере интерфейс модели заного...

Очень бы не хотелось — модели могут быть разными, и унифицировать доступ к их данным мне не нравится.

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

AF>Да вообще то ты был прав. Представление, естественно должено знать о модели — что бы извлекать из модели данные, если только ты не хочешь воспроизводить в контроллере интерфейс модели заного...

На мой взгляд, контроллер и существует чтобы сосредоточить все потоки сообщений от модели к виду и от вида к модели в одном месте...согласитесь, что выводит уровень инкапсуляции всей модели на качественно более высокий уровень. А иначе получается что вид достаточно сильно привязан к конкретной модели, а это не есть хорошо
Естественно, подход, который я предлагаю подрозумевает в некорой степени воспроизведение интерфейса модели в контроллере, но поверте это окупится. Тем более что воспроизвести интерфейс модели в контроллере можно по-разному...например, сделать его более адаптированным к запросам вида к модели

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

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

AF>>Да вообще то ты был прав. Представление, естественно должено знать о модели — что бы извлекать из модели данные, если только ты не хочешь воспроизводить в контроллере интерфейс модели заного...

D>На мой взгляд, контроллер и существует чтобы сосредоточить все потоки сообщений от модели к виду и от вида к модели в одном месте...согласитесь, что выводит уровень инкапсуляции всей модели на качественно более высокий уровень. А иначе получается что вид достаточно сильно привязан к конкретной модели, а это не есть хорошо
D>Естественно, подход, который я предлагаю подрозумевает в некорой степени воспроизведение интерфейса модели в контроллере, но поверте это окупится. Тем более что воспроизвести интерфейс модели в контроллере можно по-разному...например, сделать его более адаптированным к запросам вида к модели

Ну а адаптер на что?
А вот мне кажется, что контроллер предназначен для разделения потоков управления и данных.
И как по твоему представление можно отделить от модели? Это всё равно, что попытаться приспособить графиеский редактор к просмотру текста. В некоторых случаях — когда модель суть одна и различается лишь составом элементов (к примеру дерево одних и тех же объектов разного состава) — это возможно. Или если каждый объект модели выдаёт данные в унифицированном виде. А вот в общем случае — виду потребуется доступ к модели. Или к некоему интерфейсу для извлечения данных
И самое главное — если сделать так, как ты предлагаешь — то ты смешаешь в контроллере две обязанности — управление и преобразование данных. Если преобразование данных сложное, и его долго писать и отлаживать — то в случае, если тебе потребуется второй контроллер с другой схемой управления — ты получишь два экземпляра кода, который нужно поддерживать.
Потому контроллер должен заниматься лишь своей работой — управлять. Представление — показывать, модель — хранить данные. А если потребуется унифицировать интерфейс от модели к представлению — то пишется адаптер или делается фасад — который за это и отвечает и совершенно не зависим от изменений в контроллере.
То есть MVC => MAVC

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

AF> А вот мне кажется, что контроллер предназначен для разделения потоков управления и данных.
AF> И как по твоему представление можно отделить от модели? Это всё равно, что попытаться приспособить графиеский редактор к просмотру текста. В некоторых случаях — когда модель суть одна и различается лишь составом элементов (к примеру дерево одних и тех же объектов разного состава) — это возможно. Или если каждый объект модели выдаёт данные в унифицированном виде. А вот в общем случае — виду потребуется доступ к модели. Или к некоему интерфейсу для извлечения данных
AF> И самое главное — если сделать так, как ты предлагаешь — то ты смешаешь в контроллере две обязанности — управление и преобразование данных. Если преобразование данных сложное, и его долго писать и отлаживать — то в случае, если тебе потребуется второй контроллер с другой схемой управления — ты получишь два экземпляра кода, который нужно поддерживать.
AF> Потому контроллер должен заниматься лишь своей работой — управлять. Представление — показывать, модель — хранить данные. А если потребуется унифицировать интерфейс от модели к представлению — то пишется адаптер или делается фасад — который за это и отвечает и совершенно не зависим от изменений в контроллере.
AF> То есть MVC => MAVC


Под отделением вида от модели я подразумевал, что данные модели могут отображаться в разных формах Сама модель MVC подразумевает в себе то, что способы отображения модели(представления) можно в ходе программы либо же в ходе разработки легко сменить.
Конечно, у модели должен существовать унифицированный интерфейс мне, например, больше фасад нравится(тут я полностью солидарен ). Но этот интерфейс НЕ должен использоваться напрямую из вида. Можно, например, усложнить архитектуру контроллера и выделить в нем класс для управляющих сообщений и класс для потоков данных, если не хочется перемешивать эти 2 потока
Что же касается множественности контроллеров и трудности поддержки таких контроллеров, то необходимо просто наследовать контроллеры от одного-базового. Тогда их поддержка превращается в легкую задачку
Хочу услышать ваше мнение...

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

D>Под отделением вида от модели я подразумевал, что данные модели могут отображаться в разных формах Сама модель MVC подразумевает в себе то, что способы отображения модели(представления) можно в ходе программы либо же в ходе разработки легко сменить.
Собственно в этом и заключается предназначение модели MVC.

D>Конечно, у модели должен существовать унифицированный интерфейс мне, например, больше фасад нравится(тут я полностью солидарен ). Но этот интерфейс НЕ должен использоваться напрямую из вида. Можно, например, усложнить архитектуру контроллера и выделить в нем класс для управляющих сообщений и класс для потоков данных, если не хочется перемешивать эти 2 потока
И что случится, если представление будет пользоваться этим интерфейсом — интерфейсами модели на прямую или через адаптер?

D>Что же касается множественности контроллеров и трудности поддержки таких контроллеров, то необходимо просто наследовать контроллеры от одного-базового. Тогда их поддержка превращается в легкую задачку
Про недостатки наследования говорилось очень много. А вот преимущества такого подхода не ясны совершенно.

D>Хочу услышать ваше мнение...
Дело вот в чём: да, так как вы описываете сделать можно и это будет работать. Однако я вижу ряд недостатков (основные я описал) и не вижу каких-либо достоинств предложенного подхода, по сравнению с отдельным от контроллера, модели и представления адаптера (или фасада). Возможно они есть, и возможно очень существенные. Не могли бы вы объяснить — в чём они заключаются?

Одна и та же модель может представляться по разному. К примеру, файловая структура может быть представлена в виде дерева (как в эксплорере), а может быть как в total comander — списками. Скорее всего, можно придумать еще кучу других представлений (видов).

Данные для графика (модель) могут быть представлены графиком функции или гистограммой (а может и по другому).

С другой стороны, в виде дерева могут быть представлены разные модели — файловая система, библиотечный каталог, целая куча моделей может быть представлена в виде дерева.

Если вид "дерево" будет общаться напрямую с моделью, то его сложно будет использовать с другой моделью. Для дерева нужно получить что? Для каждого элемента важно его название и предок. Вид "дерево" вместо того, чтобы требовать у модели список файлов и получать их имена, требует у контроллера имена каких-то объектов (могут быть файлы, могут быть не файлы).

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

Контроллер (не как один класс — их может быть много — а как уровень приложения) — это прослойка между моделью и видами. Она представляет устойчивый интерфейс для видов, добавляя иммунитет видам к изменению модели, обеспечивает также то, что модель ничего не знает о тех видах, которые её могут представлять. На уровень контроллеров возлагается также поддержка навгационной логики — это один из примеров довольно сложной логики в некоторых приложениях, которая вроде бы не должна контролироваться моделью, но и если она содержится в видах, то в случае разных представлений её придется дублировать.

На практике, конечно же, нужно понимать, что кое-чем из этой модели можно пренебречь.

---

данное сообщение получено с www.gotdotnet.ru
ссылка на оригинальное сообщение

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

T>Одна и та же модель может представляться по разному. К примеру, файловая структура может быть представлена в виде дерева (как в эксплорере), а может быть как в total comander — списками. Скорее всего, можно придумать еще кучу других представлений (видов).

T>Данные для графика (модель) могут быть представлены графиком функции или гистограммой (а может и по другому).

T>С другой стороны, в виде дерева могут быть представлены разные модели — файловая система, библиотечный каталог, целая куча моделей может быть представлена в виде дерева.

T>Если вид "дерево" будет общаться напрямую с моделью, то его сложно будет использовать с другой моделью. Для дерева нужно получить что? Для каждого элемента важно его название и предок. Вид "дерево" вместо того, чтобы требовать у модели список файлов и получать их имена, требует у контроллера имена каких-то объектов (могут быть файлы, могут быть не файлы).

T>Опять-таки когда мы в видах напрямую общаемся с моделью, зачастую в код репрезентационной логики попадают довольно сложные вещи, которые приходится заново реализовывать, если система представлена разными видами (например, веб-приложение и виндоус-приложение). Что значительно усложняет поддержку разных видов (представлений одной и той же модели).

T>Контроллер (не как один класс — их может быть много — а как уровень приложения) — это прослойка между моделью и видами. Она представляет устойчивый интерфейс для видов, добавляя иммунитет видам к изменению модели, обеспечивает также то, что модель ничего не знает о тех видах, которые её могут представлять. На уровень контроллеров возлагается также поддержка навгационной логики — это один из примеров довольно сложной логики в некоторых приложениях, которая вроде бы не должна контролироваться моделью, но и если она содержится в видах, то в случае разных представлений её придется дублировать.

T>На практике, конечно же, нужно понимать, что кое-чем из этой модели можно пренебречь.

Согласен...Только полное разделение модели и вида, т.е. их взаимодействие исключительно поредством контроллера, на мой взгляд, придаст коду максимальную гибкость для повтороного использования.

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

+1 Согласен.

Если рассматривать контроллер как слой, то в этом случае всё встаёт на свои места.
Правда не совсем ясно, имеет ли смысл относить уровень адаптеров/фасадов к слою контроллера. Вроде бы они более универсальны и независимы, чем контроллер. В принципе, с моей точки зрения, задачей контроллера является управление, например, упомянутая выше сложная навигация. С этой точки зрения адаптеры для контроллера — всего лишь вспомогательные объекты, которые контроллер связывает с моделью и её представлениями. Опять-таки слой управления может поменяться кардинально — а адаптеры остаться неизменными.
Есть у медали другая сторона. Допустим, что приложение расширяемое — плагинное. В этом случае модет быть ситуация, когда модель стабильна и фиксирована, контроллер — тоже, предусмотрен так же некий обобщённый интерфейс для регистрации представлений, а так же интерфейс для общения представлений с контроллером. Нам нужно добавить представление (как отдельный модуль — плагин), без каких-либо изменений в основной системе. В этом случае может оказаться, что не был предусмотрен заранее интерфейс для общения модели с данным конкретным видом представления. И его придётся реализовывать в плагине. С данной точки зрения получается, что адаптер вообще относится к уровню представления.
Хотя в принипе в данной ситуации возможно так же (если мы предусматривали возможность расширения), можно предусмотреть возможность регистрации новых видов адаптеров и новых видов представлений отдельно друг от друга. А контроллеру по-прежнему останется их связывать и ими управлять.

То, что вы говорите про адаптеры и фасады — это все хорошо, но это лишь идеи, и если вы еще раз перечитаете их назначение, то оно немного другое.

Если вы читали GoF, то наверное заметили странную вещь, что для разных паттернов диаграмма классов как-то совсем слабо различается. Однако, смысл заложен разный. "Назначение" — как я писал в предыдущем абзаце.

Controller — это можно сказать самостоятельный паттерн. Он, конечно, может сперва показаться похожим на фасад или адаптер. Или еще на что-то. Но это не совсем так. Насколько я помню, этот паттерн рассматривался кое-где вообще без привязки к MVC. Если приложение несложное, то контроллер может быть один. Однако, часто делают по контроллеру на один Use Case. Он тогда своим интерфейсом будет похож на шаги Use Case, если так можно выразиться. Это уже серьезное различие и от фасада, и от адаптера.

---

данное сообщение получено с www.gotdotnet.ru
ссылка на оригинальное сообщение

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

T>То, что вы говорите про адаптеры и фасады — это все хорошо, но это лишь идеи, и если вы еще раз перечитаете их назначение, то оно немного другое.
Почему же другое — именно то, для которого они и предназначены — преобразование интерфейса или набора интерфейсов к некоему другому интерфейсу/набору интерфейсов.
Я их и предложил применить ровно для этой цели — для преобразования текущего интерфейса(ов) модели в интерфейс(ы), которые понимает некое представление.
Другое дело, что я не рассматриваю их как контроллер (и мне кажется, что не совсем правильно их рассматривать даже как часть контроллера)

T>Если вы читали GoF, то наверное заметили странную вещь, что для разных паттернов диаграмма классов как-то совсем слабо различается. Однако, смысл заложен разный. "Назначение" — как я писал в предыдущем абзаце.
Да, согласен, это бросается в глаза. Тут недавно обсуждали этот вопрос (раз наверное в сотый) и пришли к выводу, что это следствие применения одних и тех же основополагающих принципов, только в разных контекстах.

T>Controller — это можно сказать самостоятельный паттерн. Он, конечно, может сперва показаться похожим на фасад или адаптер. Или еще на что-то. Но это не совсем так. Насколько я помню, этот паттерн рассматривался кое-где вообще без привязки к MVC. Если приложение несложное, то контроллер может быть один. Однако, часто делают по контроллеру на один Use Case. Он тогда своим интерфейсом будет похож на шаги Use Case, если так можно выразиться. Это уже серьезное различие и от фасада, и от адаптера.

Согласен. Кроме того, что контроллер это вообще не паттерн. Это уж скорее слой — как вы и говорили ранее. Насколько я заметил где бы не рассматривалась данная тема — контроллер обходится стороной, его либо вообще не рассматривают, либо в сколзь упоминают, что мол есть такой, но реализовывать его можно по разному. То есть контроллер это скорее идея, чем чёткое решение. Правда в конкретных платформах вроде Eclipse или даже MFC по сему поводу есть более чёткие указания — но они специфичны для платформы...

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

AF>Здравствуйте, ][tiger, Вы писали:

T>>То, что вы говорите про адаптеры и фасады — это все хорошо, но это лишь идеи, и если вы еще раз перечитаете их назначение, то оно немного другое.
AF> Почему же другое — именно то, для которого они и предназначены — преобразование интерфейса или набора интерфейсов к некоему другому интерфейсу/набору интерфейсов.
AF> Я их и предложил применить ровно для этой цели — для преобразования текущего интерфейса(ов) модели в интерфейс(ы), которые понимает некое представление.
AF> Другое дело, что я не рассматриваю их как контроллер (и мне кажется, что не совсем правильно их рассматривать даже как часть контроллера)

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

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

D>Адаптеры и фасады и не являются частью контроллера...если говорить, о фасаде модели, то он просто предоставляет унифицированный интерфейс модели, а уже контроллер использует этот интерфейс с целью организации взаимодействия с видами(видом). Я это именно так понимаю

Согласен. Я и не считаю их частью контроллера. В принципе их конечно модно было бы отнести к модели, однако если рассматривать сценарий, когда нам требуется не меняя модель добавлять к ней дополнительные интерфейсы — для того, что бы показывать её данные в некотором новом представлении, то получается, что адаптеры стоит вынести в отдельный слой. Этот слой (слой адаптеров), расположен над слоем модели и используется контроллером для конфигурирования представлений.

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

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

D>>Адаптеры и фасады и не являются частью контроллера...если говорить, о фасаде модели, то он просто предоставляет унифицированный интерфейс модели, а уже контроллер использует этот интерфейс с целью организации взаимодействия с видами(видом). Я это именно так понимаю

AF>Согласен. Я и не считаю их частью контроллера. В принципе их конечно модно было бы отнести к модели, однако если рассматривать сценарий, когда нам требуется не меняя модель добавлять к ней дополнительные интерфейсы — для того, что бы показывать её данные в некотором новом представлении, то получается, что адаптеры стоит вынести в отдельный слой. Этот слой (слой адаптеров), расположен над слоем модели и используется контроллером для конфигурирования представлений.

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

Общеее замечание по паттерну MVC — коллеги, а вас нет такого впечатления, что практически каждое упоминание этого паттерна вызывает оживленную дискуссию о роли и функциях контроллера? Это наводит на мысли, что паттерн все же определен недостаточно удачно...