Объясните пожалуйста как можно свзязать
паттерн Модель — Представление — Контроллер в оконном приложении

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

Так что получается что контроллер придется делать
в виде синглетона... ?

В чем я не прав?

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

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

Контроль нужен если у нас появляется несколько сценариев обработки данных из представления

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

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

А>По Фаулеру многие ошибаются на счет этого шаболна и находят ему неправильное применение (книга "архитектура корпаротивных приложений"). В простом виде, форма-обработка, у нас контроль отсутствует и мы имеем только Модель-представление

А>Контроль нужен если у нас появляется несколько сценариев обработки данных из представления

А если несколько форм...
Получается что без контроллера не обойтись, и возникает вопрос: Как его реализовать, в виде какого паттерна?

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

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

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

А>>По Фаулеру многие ошибаются на счет этого шаболна и находят ему неправильное применение (книга "архитектура корпаротивных приложений"). В простом виде, форма-обработка, у нас контроль отсутствует и мы имеем только Модель-представление

А>>Контроль нужен если у нас появляется несколько сценариев обработки данных из представления

A>А если несколько форм...
A>Получается что без контроллера не обойтись, и возникает вопрос: Как его реализовать, в виде какого паттерна?

Насколько я понимаю классическое описание MVC, то по современным меркам роль контроллера выполняет само представление (ему ведь в бизнес-приложениях не надо рисовать хитрые картинки, все это делает ОС и библиотека). А обработчики событий контролов — вот основная часть классического представления о контроллере, а в данный момент они располагаются как раз в "формочках", классах code-behind и т.п. А контроллер, в моем понимании на данный момент, выполняет роль координатора некоторого процесса (например, сценария использования), то есть управляет последовательностью показа форм и моментами, например, сохранения модели в БД. Правда, там по науке контроллеров разных — пруд пруди
По логике вещей, вью должен иметь возможность передать контроллеру, его вызвавшему, команды пользователя. Соответственно, контроллер получает откуда-то команду запустить процесс, показывает первый вью. На нем пользователь выполняет какие-то действия и команды, которые представление (выборочно, естественно) передает контроллеру. По факту выполнения какой-то команды контроллер принимает решение предпринять какие-то действия (например, закрыть (или не закрывать) этот вью и показать следующий).
По большому счету нет тут никакого паттерна. Как вариант, класс реализующий некоторое количесткво интерфейсов (по количеству вью им обслуживаемых) или имеющий некий обобщенный (соответственно, мало типизированный) интерфейс.
Ничего другого в голову не лезет.
Если не прав — поправьте пока не поздно

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

A>По идее он должен содержать в себе текущую информацию и передавать ее
A>представлениям
Зачем держать? У тебя есть модель. В ней данные. Контроллер только связывает их.

A>Так что получается что контроллер придется делать
A>в виде синглетона... ?
Зачем? Делай как тебе удобно. Просто нужно видеть цель контроллера. А цель у него проста — сделать независимость Модели и Представления, и то, что обычно на одну модель приходится множество представлений. Будет ли у тебя один контроллер обслуживать все предстваления, или будет несколько, или на каждое — это уже частности. Делай как тебе удобно. Главное выполнить цель.

С уважением, Gleb.

Здравствуйте, Козьма Прутков, Вы писали:

КП>Насколько я понимаю классическое описание MVC, то по современным меркам роль контроллера выполняет само представление (ему ведь в бизнес-приложениях не надо рисовать хитрые картинки, все это делает ОС и библиотека). А обработчики событий контролов — вот основная часть классического представления о контроллере, а в данный момент они располагаются как раз в "формочках", классах code-behind и т.п. А контроллер, в моем понимании на данный момент, выполняет роль координатора некоторого процесса (например, сценария использования), то есть управляет последовательностью показа форм и моментами, например, сохранения модели в БД. Правда, там по науке контроллеров разных — пруд пруди
КП>По логике вещей, вью должен иметь возможность передать контроллеру, его вызвавшему, команды пользователя. Соответственно, контроллер получает откуда-то команду запустить процесс, показывает первый вью. На нем пользователь выполняет какие-то действия и команды, которые представление (выборочно, естественно) передает контроллеру. По факту выполнения какой-то команды контроллер принимает решение предпринять какие-то действия (например, закрыть (или не закрывать) этот вью и показать следующий).
КП>По большому счету нет тут никакого паттерна. Как вариант, класс реализующий некоторое количесткво интерфейсов (по количеству вью им обслуживаемых) или имеющий некий обобщенный (соответственно, мало типизированный) интерфейс.
КП>Ничего другого в голову не лезет.
КП>Если не прав — поправьте пока не поздно

Но где должен создаваться объект контроллер и модель вместе с ним
Допустим если разработка ведется под Win на C++

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

A>С моделью и представлением все ясно,
A>но как должен выглядеть контроллер, как его реализовать
A>По идее он должен содержать в себе текущую информацию и передавать ее
A>представлениям

A>Так что получается что контроллер придется делать
A>в виде синглетона... ?

A>В чем я не прав?

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

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

Представление содержит в себе код, связанный только с отображением, некоторой информации.
Модель -- содержит в себе данные в некотором виде, и методы работы с ними.
А вот код, который преобразовывает данные из модели в представление, и назад -- и есть контроллер.

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

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

A>>С моделью и представлением все ясно,
A>>но как должен выглядеть контроллер, как его реализовать
A>>По идее он должен содержать в себе текущую информацию и передавать ее
A>>представлениям

A>>Так что получается что контроллер придется делать
A>>в виде синглетона... ?

A>>В чем я не прав?

_>1. При чем здесь синглтон? Контроллер нужен для связи представления и модели. На каждую такую связь может приходиться отдельный контроллер. Если логика контроллера не очень сложная, он может в себе объединять бОльшее кол-во связей. В общем, "добавляем по вкусу" (С).

Тогда вопрос:
Имел еще ввиду использовать синглтон, для данных которые должны быть доступны всем представлением/контролерам
Или же есть другой выход....

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


_>>1. При чем здесь синглтон? Контроллер нужен для связи представления и модели. На каждую такую связь может приходиться отдельный контроллер. Если логика контроллера не очень сложная, он может в себе объединять бОльшее кол-во связей. В общем, "добавляем по вкусу" (С).

A>Тогда вопрос:
A>Имел еще ввиду использовать синглтон, для данных которые должны быть доступны всем представлением/контролерам
A>Или же есть другой выход....

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

Использую сейчас контроллеры в приложении следующим образом.

Контроллер имеет следующую структуру:

TController = class
private
FObject: TAnyObject;
procedure AddObject;
procedure EditObject;
procedure DeleteObject;
function ValidateForm(Sedner: TComponent): boolean;

procedure LoadFromObject(Obj: TAnyObject; Form: TAnyForm);
procedure SaveToObject(Obj: TAnyObject; Form: TAnyForm);

procedure ShowObjectList;
public
constructor Create;
destructor Destroy;
end;

Формы имеет следующую струткуру:
TAnyForm = class(TForm)
...
public
property OnAddObject;
property OnEditObject;
property OnDeleteObject;
property OnValidateForm;
end;


TMainForm = class(TForm)
...
public
property OnShowObjectList;
end;

При создании контроллер навешивает обработчик на главную форму для запуска метода ShowObjectList;
Основная форма инициализирует вызов метода, которая приводит к открытию формы TAnyForm.
Перед тем как показать форму инициализируются свойства OnAddObject, OnEditObject, OnDeleteObject.

При вызове метода AddObject и EditObject вызывается форма на редактирование. Методы LoadFromObject и SaveToObject позволяют загружать и сохранять данные формы. Метод ValidateForm проверяет данные на корректность.


В основном контроллер у меня работает с 2 объектами и 2-4-ми формами.

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

A>Объясните пожалуйста как можно свзязать
A>паттерн Модель — Представление — Контроллер в оконном приложении

A>С моделью и представлением все ясно,
A>но как должен выглядеть контроллер, как его реализовать
A>По идее он должен содержать в себе текущую информацию и передавать ее
A>представлениям

A>Так что получается что контроллер придется делать
A>в виде синглетона... ?

A>В чем я не прав?

Сначала напиши базовые классы модели контролера и представления и они не должны быть синглетонами, только фабрика классов синглетон.
Определись какой способ связывания т.е. поток данных model->controller->view and callback view->controller->model or view->model->controller есть разные варианты.

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

DP> view->model->controller
Можно по подробнее.

С уважением, Gleb.

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

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

DP>> view->model->controller
GZ>Можно по подробнее.

GZ>С уважением, Gleb.

Да можно и так — вьюшка передает непосредственно в модель изменения а модель извещает контроллер и тот в свою очередь заполняет данными свои вьюшки.
Лично я обычно использую схему Model<=>Controller<=>View т.е. Model и View общаются только через контроллер, но существуют и другие варианты.

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

DP>Да можно и так — вьюшка передает непосредственно в модель изменения а модель извещает контроллер и тот в свою очередь заполняет данными свои вьюшки.
DP>Лично я обычно использую схему Model<=>Controller<=>View т.е. Model и View общаются только через контроллер, но существуют и другие варианты.
Эта шняга называется Builder. А MCV — другой паттерн.

С уважением, Gleb.

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

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

DP>>Да можно и так — вьюшка передает непосредственно в модель изменения а модель извещает контроллер и тот в свою очередь заполняет данными свои вьюшки.
DP>>Лично я обычно использую схему Model<=>Controller<=>View т.е. Model и View общаются только через контроллер, но существуют и другие варианты.
GZ>Эта шняга называется Builder. А MCV — другой паттерн.

GZ>С уважением, Gleb.

мда ... где Билдер ?

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

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

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

DP>>>Да можно и так — вьюшка передает непосредственно в модель изменения а модель извещает контроллер и тот в свою очередь заполняет данными свои вьюшки.
GZ>>Эта шняга называется Builder. А MCV — другой паттерн.
DP>мда ... где Билдер ?
Ну не Билдер, а что-то в виде стратегии. Замени порождение на заполнение, будет то же самое. Ну нет такого паттерна (по крайней мере я не могу найти чистые аналогии), потому как смысла в этом нет. Основной смысл — независимость модели от представления. В данном случае — оно не выполняется. Это точно не MCV.

С уважением, Gleb.

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

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

А>По Фаулеру многие ошибаются на счет этого шаболна и находят ему неправильное применение (книга "архитектура корпаротивных приложений"). В простом виде, форма-обработка, у нас контроль отсутствует и мы имеем только Модель-представление

А>Контроль нужен если у нас появляется несколько сценариев обработки данных из представления
http://www.martinfowler.com/eaaDev/ModelViewPresenter.html

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

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

A>>Объясните пожалуйста как можно свзязать
A>>паттерн Модель — Представление — Контроллер в оконном приложении

A>>С моделью и представлением все ясно,
A>>но как должен выглядеть контроллер, как его реализовать
A>>По идее он должен содержать в себе текущую информацию и передавать ее
A>>представлениям

A>>Так что получается что контроллер придется делать
A>>в виде синглетона... ?

A>>В чем я не прав?

DP>Сначала напиши базовые классы модели контролера и представления и они не должны быть синглетонами, только фабрика классов синглетон.
DP>Определись какой способ связывания т.е. поток данных model->controller->view and callback view->controller->model or view->model->controller есть разные варианты.

допустим я написал классы моделт/педставления/вида и выбрал самый простой (как мне кажется)
вид — > контроллер — > модель

что делать дальше каким способом можно реализовать этот поток?

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

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

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

A>>>Объясните пожалуйста как можно свзязать
A>>>паттерн Модель — Представление — Контроллер в оконном приложении

A>>>С моделью и представлением все ясно,
A>>>но как должен выглядеть контроллер, как его реализовать
A>>>По идее он должен содержать в себе текущую информацию и передавать ее
A>>>представлениям

A>>>Так что получается что контроллер придется делать
A>>>в виде синглетона... ?

A>>>В чем я не прав?

DP>>Сначала напиши базовые классы модели контролера и представления и они не должны быть синглетонами, только фабрика классов синглетон.
DP>>Определись какой способ связывания т.е. поток данных model->controller->view and callback view->controller->model or view->model->controller есть разные варианты.

A>допустим я написал классы моделт/педставления/вида и выбрал самый простой (как мне кажется)
A>вид — > контроллер — > модель

A>что делать дальше каким способом можно реализовать этот поток?

Пример: связь MVC для варианта когда у модели много контроллеров и у контроллера много моделей и много вьюшек, и у вьюшки много контроллеров.

базовые абстрактные классы:

class Model
{
AddController(функция добавления в m_ListController);

std::list<Controller*> m_ListController;
};

class Controller
{

AddModel(функция добавления в m_ListModel);
AddView(функция добавления в m_ListView);

std::list<Model*> m_ListModel;
std::list<View*> m_ListView;
};

class View
{

AddController(функция добавления в m_ListController);

std::list<Controller*> m_ListController;
};

использование:

Model* MyModel=new Model;

Controller* MyController=new Controller;

View* MyView=new View;

Model->AddController(MyController);
Controller->AddModel(MyModel);
Controller->AddView(MyView);
View->AddController(MyController);

Это всё упращенно и поэтому должно быть всё понятно.

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


DP>Пример: связь MVC для варианта когда у модели много контроллеров и у контроллера много моделей и много вьюшек, и у вьюшки много контроллеров.

DP>базовые абстрактные классы:

DP>class Model
DP>{
DP> AddController(функция добавления в m_ListController);

DP> std::list<Controller*> m_ListController;
DP>};

DP>Это всё упращенно и поэтому должно быть всё понятно.

Но модель же не должна знать о контроллерах?

Спасибо.