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

Так вот у меня несколько вопросов:
1) Модель.
Это класс содержащий (внутри себя) все данные для отображения во View или класс, предоставляющий доступ к базе данных, с помощью которого берутся данные для отображения во View?

У меня есть оба класса и "класс предоставляющий доступ к базе данных", и "класс содержащий все данные для отображения". Вот только кто из них кто --- непонятно   

2) Контроллер и его роль.
Он реагирует на тыканье пользователем кнопок --- это точно. Но как глубоко?

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

Спасибо за каждое мнение по вопросу.
ivashkanet

P.S. База данных не стандартная, так что "класс предоставляющий доступ к базе данных" необходим.

ivashkanet, почитай: http://martinfowler.com/eaaDev/SupervisingPresenter.html

Это класс который предоставляет доступ к данным (get/set и т.п.). Как и где он их хранит, это его личное дело View не должен об этом заботится.



Он изменяет Model через ее методы доступа к данным. Model в свою очередь должна будет уведомить View что данные изменились.


У Model должен быть способ уведомления всех заинтересованных компонентов, о том что данные изменились.

ivashkanet, если бы ты прочитал внимательно статью, то нашел бы там ответы на все свои вопросы   

В двух словах:

1) Model - это твой business layer (сущности, сервисы, и проч.)

2) View - это интерфейс, описывающий контракт нужного тебе представления:



Данный интерфейс реализуется в форме LoginForm.

3) Presenter (Controller) - это управляющий класс, который подписывается на события view, на интересующие его события model, и содержащий логику реакции на эти события. Например, для логина:



Теперь стало более понятно?

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

Так вот: кто из них относится к Model, а кто к View????

Перечитал пост  arilou еще раз и понял... , что они оба составляют Model  Т.е. мне их нужно собрать в один класс 
Я прав???

У меня жесткая связь: "данные, которые показывают гриды" (которые, вроде, должны быть в модели) 1 к 1 отображаются на гриды во View.

Извините, я неправильно выразился. Не данные должны измениться, а набор данных.
Т.е. во второстепенных таблицах должны быть данные, которые касаются выделенной строки в главном гриде.

Прочитал, но, наверное, не совсем внимательно. Потому что до сих пор не очень понимаю...

На твоем примере --- да, но как быть с моим?

ИМХО, главный момент --- то что гриды в .Net не хранят данные для отображения. Поэтому об этом должен заботиться отдельный класс. К кому он относиться? К модели или отображению? от этого будет зависеть логика приложения

Добавлено @ 15:21 
Еще уточнения:
"класс предоставляющий доступ к базе данных" --- это данные как они есть, как они представлены в БД.
"класс содержащий все данные для отображения" ---- это класс содержащий данные в том виде, каком их увидит пользователь, они составлены из разных элементов первого класса. И только те, которые увидит пользователь.

Это сообщение отредактировал(а) ivashkanet - 20.11.2006, 15:24

Совсем не обязательно. Модель - это те классы из бизнес и дата уровней, которые понадобятся для реализации данной конкретной формы. Для разных форм они вполне могут пересекаться.


Класс, хранящий ссылки на данные для отображения безусловно относится к отображению. Просто дело всё в том, что его можно использовать и для других целей, например передачу его на уровень данных для обновления БД. Например, можно использовать датасет. Или кастомные сущности. Это как тебе проще.


Исходя из того, что я написал выше, оба класса относятся к модели, либо класс БД - к модели, а класс, содержащий данные, - к представлению.

1. Есть некая парадигма, а есть ее реализация. И реализация может не полностью соответсвовать этой модели. Например в Swing - View и Controller объеденены (как я понимаю в .NET, тоже).
2. Модель это тот класс к которому обращается View за данными. Гриды обращаются напрямую к классу который представляет собой интерфейс к БД? Нет? Значит класс работающий с БД, вообще в MVC не участвует, он вспомогательный для Model.



Это пволне естественно. В чем вопрос?

А по каким критериям я должен выбрать кто к мому относится?

Если я сделаю моделью только "класс предоставляющий доступ к базе данных", то у меня будет единая модель для всех View системы (с интерфейсами: события --- такой-то объект изменился и методами --- дай мне такой-то объект. Интерфейс на изменение модели находится в другом классе).

Но тогда будет немного нехорошая (а может не такая уж и плохая) цепочка сообщений:
1) (View --> Controller) Выделенная строка изменилась (можно ли в это событие завернуть измененные данные?).
2) (Controller --> View) Дай текущие данные.
3) (Controller --> части View которая отвечает за хранение данных для отображение) Для всех второстепенных таблиц: если изменения касаются таблицы, то изменить таблицу.

P.S. Давайте, пока, считать, что я не изменяю данные модели, я только их отображаю. Таким образом я управляю только тем что и как отображать 

View - только отображает данные. Менять данные может или Controller или Model (Model менят их если они изменились в "хранилище", а не в результате действий пользователя).


У View нет текущих данных, он их не хранит.

Model в принципе хранит данные для этображения, а не только отвечает за их загрузку из БД и сохранение. Если нужны данные то и Controller и View обращаются именно к Model за данными.

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

Ага, вот это дельная мысль.  Которая все сразу расставляет на свои места   

Но. Контроллер тоже будет обращаться к этому классу. Значит это все-таки часть модели, а не вспомогательный для модели класс.

P.S. Должна ли модель быть представлена внешне одним классом, таким образом View и Controller будут знать только об одном классе? Если классов несколько --- не нужно ли строить паттерн Фасад для этих классов?

Добавлено @ 16:08 

Вернее не "дай текущие данные", а "дай информацию  о строке, которую выделил пользователь".

Опять не так выразился, извините: "Пользователь изменил выделенную строку".

А этого он не должен делать. Модель должна содержать все необходимые методы для манипуляции данными. Иначе станет невозможно изменить ее реализацию.


Да. Этот класс должен представлять методы для: чтения данных, изменения данных, регистрации слушателей изменения данных. Можно сделать его в виде интерфейса. Интерфейс не должен выносить наружу как и откуда получаются данные. Они есть и этого достаточно.

Добавлено @ 16:14 
Данные о пользовательском вводе получает контроллер, а не вид. Контроллер или меняет данные в модели или говорит виду изменить отображение данных (например выделить строку). Вид только отображает данные из модели, иногда моделей может быть несколько, например TableModel и SelectionModel.

Подведу-ка я промежуточные итоги:
1) View не хранит никаких данных. 
2) Данные нужные View для отображения находятся в Model. 
3) View берет их 1:1 и отображает. 
4) View не отвечает за компоновку нужных ей данных (например в БД две таблицы, а отображаем мы одну --- объединение этих двух таблиц) этим занимается модель.
5) Если пользователь изменил выделенную строку (но не изменил данные), то Controller должен дать команду Model, чтобы она изменила данные, которые отображает View.
Кто должен знать алгоритм изменения данных отображения? Controller? Или это может знать сама Model?
6) View слизывает изменившиеся данные с модели.

Уфф, столько вопросов   Надо было мне сразу оговорится, что паттерн Model View Controller и паттерн Model View Presenter (Supervising Controller) - не совсем одно и то же. Я писал про MVP. Вот сжатое описание.

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

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

Сама форма (Form в дотнете) хранит либо отображаемые в ней данные (в случае value types), либо ссылки на них. 

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

LSD, arilou, у меня такое ощущение, что я не совсем понимаю этот паттерн  

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

А тут получается соооовсем другая история:
1) View отображает данные и уведомляет контроллер о том, что пользователь что-то сделал.
2) Контроллер производит первоначальную обработку события.
3) ВСЕ дела делает модель. Изменение данных, изменение отображаемого View набора данных, ВСЯ бизнес логика приложения.

В этом случае -- да, контроллер и View легко объединяются в один компонент. Потому что никто из них не делает сложную работу. Всю сложную работу делает Model.

У меня возникает вопрос: Где же разделение труда? Mode делает всю "грязную" работу, а View и Controller разбрасываются командами --- сделай то, сделай это...

Почему бы не нагрузить View и Controller частью функций (см. то что я считал раньше), с которыми они легко справятся?