Re[5]: Модель представление контроллер - Архитектура программного обеспечения

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

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

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

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

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

... << RSDN@Home 1.1.3 stable >>

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

... << RSDN@Home 1.1.3 stable >>

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

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

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

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

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

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

Неужели?!

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

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

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

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

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

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

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

... << RSDN@Home 1.1.4 beta 4 rev. 303>>

Здравствуйте, 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.

... << RSDN@Home 1.1.4 beta 4 rev. 358>>

Здравствуйте, 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.

... << RSDN@Home 1.1.4 beta 4 rev. 358>>

Здравствуйте, 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.

... << RSDN@Home 1.1.4 beta 4 rev. 358>>

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

А>Здравствуйте, 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 есть разные варианты.

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

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

... << RSDN@Home 1.1.4 beta 4 rev. 303>>

Здравствуйте, 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>Это всё упращенно и поэтому должно быть всё понятно.

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

Спасибо.

... << RSDN@Home 1.1.4 beta 4 rev. 303>>

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

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

A>Спасибо.

Смысл MVC — отделить бизнес-логику от представления, т.е. во View не должно быть ни какой БЛ а только отображение данных и передача в Контроллер реакции (событий) (действий) (нажатия на кнопки и т.п.).

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

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

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

A>>Спасибо.

DP>Смысл MVC — отделить бизнес-логику от представления, т.е. во View не должно быть ни какой БЛ а только отображение данных и передача в Контроллер реакции (событий) (действий) (нажатия на кнопки и т.п.).

то есть под событиями подразумевается изменение данных в модели
то есть юзер изменил что то в одном виде — изменение пошло в модель через конртроллер,
а потом на все контроллеры и через них на все остальные виды?

Но можно же вообще отделить модель переложить эту задачу только на контроллеры?

... << RSDN@Home 1.1.4 beta 4 rev. 303>>

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

A>то есть под событиями подразумевается изменение данных в модели
A>то есть юзер изменил что то в одном виде — изменение пошло в модель через конртроллер,
A>а потом на все контроллеры и через них на все остальные виды?

A>Но можно же вообще отделить модель переложить эту задачу только на контроллеры?

Можно, способов раелизации MVC много и нужно использовать наиболее подходящий в каждом конкретном случаии, а не бездумно лепить стандартный шаблон ко всем ситуациям. Но если сразу очень сложно спроектировать архитектуру программы то можно начать с простого .... к сложному.

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

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

A>>то есть под событиями подразумевается изменение данных в модели
A>>то есть юзер изменил что то в одном виде — изменение пошло в модель через конртроллер,
A>>а потом на все контроллеры и через них на все остальные виды?

A>>Но можно же вообще отделить модель переложить эту задачу только на контроллеры?

DP>Можно, способов раелизации MVC много и нужно использовать наиболее подходящий в каждом конкретном случаии, а не бездумно лепить стандартный шаблон ко всем ситуациям. Но если сразу очень сложно спроектировать архитектуру программы то можно начать с простого .... к сложному.

именно так и хочется сделать
отсюда возникают два вопроса:

1) Сколько в средне приходиться перерабатывать архитектуру приложения?
2) Какие источники нужно использовать, в смысле где описывается и где есть примеры MVC?

... << RSDN@Home 1.1.4 beta 4 rev. 303>>

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

A>

A> именно так и хочется сделать
A> отсюда возникают два вопроса:

A> 1) Сколько в средне приходиться перерабатывать архитектуру приложения?
A> 2) Какие источники нужно использовать, в смысле где описывается и где есть примеры MVC?

1. Переделывать только в случае если вдруг сильно меняется ТЗ и это влияет на архитектуру.
Может быть только доработка.

2. Читай Э.Гамма Р.Хелм ... "Примеры объектно-ориентированного проектирования".

Смотри примеры для Java,C#.

http://msdn.microsoft.com/architecture/patterns/default.aspx?pull=/library/en-us/dnpatterns/html/DesMVC.asp

http://java.sun.com/blueprints/patterns/MVC-detailed.html

исходник на С#
http://codeproject.com/gen/design/MVC1.asp

Здравствуйте, Adopt, Вы писали:
Два топика рядом (Model-View-Controller pattern — как это делают в .NET?) это прикольно

Sincerely Mine ... AlLucky Sly << RSDN@Home 1.1.4 Track0 >>

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

DP>2. Читай Э.Гамма Р.Хелм ... "Примеры объектно-ориентированного проектирования".

В GoF MVC не описан.

... << RSDN@Home 1.1.4 beta 5 rev. 412>>

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

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

DP>>2. Читай Э.Гамма Р.Хелм ... "Примеры объектно-ориентированного проектирования".

AVK>В GoF MVC не описан.

Да это ты точно подметил, но объектно-ориентированное проектирование тоже знать надо

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

Как это делал я. Идея такая.
Модель содержит коллекцию геометрий.
Вьюшка отображает модель и передаёт сообщения системы контроллерам.
Контроллеры делают основную работу по модификации данных модели и режимов отображения вьюшки.

Модель:

class CVisualizationDoc : public CDocument
{
public:
    ...
    // Тут методы для доступа к данным и т.п.
    ...
};

Вьюшка:

class CVisualizationView : public CView
{
public:
    ...
    virtual void OnDraw(CDC* pDC); 
    afx_msg void OnLButtonUp(UINT nFlags, CPoint point);
    afx_msg void OnLButtonDown(UINT nFlags, CPoint point);
    afx_msg void OnMouseMove(UINT nFlags, CPoint point);
    ...
private:
    Controller* m_pActiveController;
};

// Выбираем текущий контроллер, кнопками на тулбаре
void CVisualizationView::OnController(UINT uID)
{
    m_uCurrentControllerID = uID;
    delete m_pActiveController;
    switch(m_uCurrentControllerID)
    {
    // Меняем область отображения у вьюшки
    case ID_CONTROLLER_ZOOM_IN:
        m_pActiveController = new ZoomInController(this);
        break;
    case ID_CONTROLLER_ZOOM_OUT:
        m_pActiveController = new ZoomOutController(this);
        break;
    // Редактируем существующие обьекты, модифицируем модель
    case ID_CONTROLLER_EDIT:
        m_pActiveController = new EditController(this);
        break;
    case ID_CONTROLLER_CREATE:
        m_pActiveController = new CreatePolygonController(this);
        break;
    default:
        m_pActiveController = NULL;
    }
}

// Отрисовываем выбраный - нажатым
void CVisualizationView::OnUpdateController(CCmdUI* pCmdUI)
{
    pCmdUI->SetCheck(pCmdUI->m_nID == m_uCurrentControllerID);
}

// Вьюшка получила сообщение от системы(пользователя) которое обрабатывает контроллер
void CVisualizationView::OnMouseMove(UINT nFlags, CPoint point)
{
    if(m_pActiveController != NULL)
        m_pActiveController->OnMouseMove(nFlags, point);
    CView::OnMouseMove(nFlags, point);
}

...

Контроллер:

// Базовый контроллер, дочерние переопределяют необходимые им методы и т.д.
class Controller
{
public:
    Controller(CVisualizationView* pView);
    virtual ~Controller();
    virtual void OnLButtonDown(UINT nFlags, CPoint point) {}
    virtual void OnLButtonUp(UINT nFlags, CPoint point) {}
    virtual void OnMouseMove(UINT nFlags, CPoint point) {}
    virtual void OnDraw(CDC* pDC) {}
protected:
    CVisualizationView* m_pView;
};

... << RSDN@Home 1.1.4 beta 5 rev. 395>>

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

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

а где располагалися объект модели

То есть View содержала указательна контроллер
Controller содержал указатель на View

А кто содержал указатель на сами данные?

... << RSDN@Home 1.1.4 beta 6 rev. 422>>

A>а где располагалися объект модели

Это ж сделано на базе MFC Document/View Architecture.
Модель — это Документ:

class CVisualizationDoc : public CDocument{
...
};

и указатель на документ получается просто:

m_pDoc = m_pView->GetDocument();

... << RSDN@Home 1.1.4 beta 5 rev. 395>>

	От:	Adopt
	Дата:	23.03.05 23:40
	Оценка:

	От:	Аноним
	Дата:	24.03.05 09:01
	Оценка:

	От:	Adopt
	Дата:	25.03.05 04:07
	Оценка:

	От:	Козьма Прутков
	Дата:	25.03.05 10:45
	Оценка:

	От:	GlebZ
	Дата:	25.03.05 18:37
	Оценка:

	От:	DigitPower
	Дата:	02.04.05 08:16
	Оценка:	1 (1)

От:	AlLucky	Qulix Systems
Дата:	09.04.05 10:52
Оценка:

От:	AndrewVK	http://blogs.rsdn.org/avk
Дата:	17.04.05 08:13
Оценка:

	От:	_wqwa
	Дата:	27.03.05 07:56
	Оценка:

	От:	_wqwa
	Дата:	28.03.05 08:01
	Оценка:

	От:	maxal
	Дата:	21.04.05 14:52
	Оценка:

	От:	maxal
	Дата:	25.04.05 10:41
	Оценка: