Здравствуйте. Возникли следущие вопросы по 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 — коллеги, а вас нет такого впечатления, что практически каждое упоминание этого паттерна вызывает оживленную дискуссию о роли и функциях контроллера? Это наводит на мысли, что паттерн все же определен недостаточно удачно...

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

---

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

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

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

Или наоборот — слишком удачно. Ведь обсуждается-то не вопрос о том, применять его или нет, а то, как именно его реализовывать и применять.
По-моему дело тут в том, что MVC — это не просто конкретный шаблон — вроде той же Factory, а скорее некое общее архитектурное решение. Ведь в общем случае и Model и View и Controller — это не просто отдельные классы, а скорее целые слои.

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


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


В документации к библиотеке классов SFL (Stingray Foundation Library), которая входит в состав ихнего Grid-а (и других продуктов), говорится что у вида есть ссылка на модель, но эта сссылка должна быть слабой. В их примерах класс, реализующий конкретный вид, содержит указатель на базовый библиотечный класс модели (из которого порождена конкретная модель).

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

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

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

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

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

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

В той же Stringray Foundation Library предлагают для этого дела так называемую presentation model, которую можно вставлять между видом и основной моделью (кажется это похоже на то, что здесь описывают). Там рассматривается пример, очень схожий с тем, который приводил ][tiger насчет файловой структуры.
В их примере они рассматривают, кажется, абстрактную программу для разработки электрических схем. В этом примере, отдельные виды могут не хотеть знать о том, что они отображают именно элементы элетрической схемы — и поэтому эти виды обращаются за данными не к основной модели, а к презентационной модели (которая поставляет виду только визуальные характеристики элементов).

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

LD>В той же Stringray Foundation Library предлагают для этого дела так называемую presentation model, которую можно вставлять между видом и основной моделью (кажется это похоже на то, что здесь описывают). Там рассматривается пример, очень схожий с тем, который приводил ][tiger насчет файловой структуры.
Собственно это мы и обсуждали. Вопрос был только лишь в том, к кому из троицы модель-представление-контроллер или к кому-то четвёртому относить функцию преобразования интерфейса модели к интерфейсу вида. Вот тут мнения разделились...

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

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


LD>В документации к библиотеке классов SFL (Stingray Foundation Library), которая входит в состав ихнего Grid-а (и других продуктов), говорится что у вида есть ссылка на модель, но эта сссылка должна быть слабой. В их примерах класс, реализующий конкретный вид, содержит указатель на базовый библиотечный класс модели (из которого порождена конкретная модель).

Не буду спорить с создателями SFL, у них, очевидно, в силу реализации подобного подхода были какие-то свои мотивы Я постараюсь объяснить какие недостатки я вижу в этом подходе:
1. невозможность унифицированного контроля потоков сообщений и данных между моделью и видом
2. модели отображаемые видом вовсе не обязательно пораждаются от одного абстракного класса

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

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

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

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

А>Спасибо.

Надеюсь будет полезна:
http://rsdn.ru/Forum/Message.aspx?mid=1103088

Автор: DigitPower
Дата: 01.04.05

_FR>

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

прочитал вид как баг...