Re: ModelPresenterView и служебные диалоги - Архитектура программного обеспечения

1 2 >|

ModelPresenterView и служебные диалоги

	От:	Аноним
	Дата:	21.11.07 11:13
	Оценка:

Пусть, используя MPV, мы создали приложение:
Presenter отбражает результаты работы счётного части (Model) на несколько форм(Views).
Скажем, три формы (View1,View2,View3) с разными графиками, один Presenter, одна Model.
Вопрос: чем должны являться модальные диалоги (10 штук), задающие параметры алгоритма ?

Делать их все View вроде не стоит логически, и накладно физически, т.к. для каждый View
реализует своё интерфейс IView.

С другой стороны, результат их ввода нужен Presenter'у: он забирает результат и сохраняет его в модели.

Можно, конечно, интерфейс диалогов реализовать в интерфейсах одного или нескольких View, с тем, чтобы они просто переадресовали запросы нужным диалогам. Т.е. для Presenter'a этих диалогов не существует — он видит только интерфейсы View1,2,3.

В сомнениях. Поделитесь опытом.

Re: ModelPresenterView и служебные диалоги

	От:	kejroot
	Дата:	21.11.07 13:36
	Оценка:

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

А>Пусть, используя MPV, мы создали приложение:
А>Presenter отбражает результаты работы счётного части (Model) на несколько форм(Views).
А>Скажем, три формы (View1,View2,View3) с разными графиками, один Presenter, одна Model.
А>Вопрос: чем должны являться модальные диалоги (10 штук), задающие параметры алгоритма ?

модальные диалоги — вроде плохой тон в юзабилити...

А>Делать их все View вроде не стоит логически, и накладно физически, т.к. для каждый View
А>реализует своё интерфейс IView.

а нельзя для всех диалогов один интерфейс, он ведь единообразно с данными работает, а для данных — базовый объект модели с наследниками для разных наборов параметров

А>С другой стороны, результат их ввода нужен Presenter'у: он забирает результат и сохраняет его в модели.

А>Можно, конечно, интерфейс диалогов реализовать в интерфейсах одного или нескольких View, с тем, чтобы они просто переадресовали запросы нужным диалогам. Т.е. для Presenter'a этих диалогов не существует — он видит только интерфейсы View1,2,3.

Re: ModelPresenterView и служебные диалоги

От:	Stormblast	http://www.myspace.com/stormblastblack
Дата:	21.11.07 14:12
Оценка:	+1

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

А>Пусть, используя MPV, мы создали приложение:
А>Presenter отбражает результаты работы счётного части (Model) на несколько форм(Views).
А>Скажем, три формы (View1,View2,View3) с разными графиками, один Presenter, одна Model.
А>Вопрос: чем должны являться модальные диалоги (10 штук), задающие параметры алгоритма ?

А>Делать их все View вроде не стоит логически, и накладно физически, т.к. для каждый View
А>реализует своё интерфейс IView.

А>С другой стороны, результат их ввода нужен Presenter'у: он забирает результат и сохраняет его в модели.

А>Можно, конечно, интерфейс диалогов реализовать в интерфейсах одного или нескольких View, с тем, чтобы они просто переадресовали запросы нужным диалогам. Т.е. для Presenter'a этих диалогов не существует — он видит только интерфейсы View1,2,3.

А>В сомнениях. Поделитесь опытом.

для начала может быть поможет быть http://rsdn.ru/Forum/message/2566219.1.aspx

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

Re[2]: ModelPresenterView и служебные диалоги

	От:	shvonder
	Дата:	21.11.07 14:18
	Оценка:

Здравствуйте, kejroot, Вы писали:
K>модальные диалоги — вроде плохой тон в юзабилити...
Меня интересует архитектура ModelViewPresenter и ModelViewController применительно к повсеместно используемым модальным и немодальным диалогам, а не хорошие манеры в юзабилити.

K>а нельзя для всех диалогов один интерфейс, он ведь единообразно с данными работает,
K>а для данных — базовый объект модели с наследниками для разных наборов параметров

Не понял. Из одного диалога забираем список выделенных каналов, из другого — расчитанный вектор времени, из третьего — праметры хитровы@@аного интегрального преобразования, на четвёртом прогрессбар развлекает пользователя и т.д. — разброд, шатание и никаких общих интерфесов

Как это подать в Presenter, чтобы быстро и по науке ?

Re[3]: ModelPresenterView и служебные диалоги

	От:	kejroot
	Дата:	21.11.07 14:28
	Оценка:

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

S>Здравствуйте, kejroot, Вы писали:
K>>модальные диалоги — вроде плохой тон в юзабилити...
S>Меня интересует архитектура ModelViewPresenter и ModelViewController применительно к повсеместно используемым модальным и немодальным диалогам, а не хорошие манеры в юзабилити.

ка хотице..

K>>а нельзя для всех диалогов один интерфейс, он ведь единообразно с данными работает,
K>>а для данных — базовый объект модели с наследниками для разных наборов параметров

S>

ну значт пустой интерфейс общий

он же базовый! главное, что он используется в общем интерфейсе диалога!

S>Как это подать в Presenter, чтобы быстро и по науке ?
я не знаю.

Re[2]: ModelPresenterView и служебные диалоги

	От:	shvonder
	Дата:	21.11.07 14:43
	Оценка:

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

S>Здравствуйте, Аноним, Вы писали:
S>для начала может быть поможет быть http://rsdn.ru/Forum/message/2566219.1.aspx

Основательно..

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

) контроллер в ModelViewController
отвечал за события, пришедшие не с гуя, в отличие от современных библиотек, где View есть источник событий — всякие клики на форме и проч. Отсюда преврашение ModelViewController в DocunentView, где
Document = View + Controller.
А в ModelViewPresenter из гуя вынесли по-возможности всю логику, и перенесли в Presenter. Т.е. Presenter, реагируя на событие гуя(View), забирает данные из него, передаёт в счётное ядро(Model),
забирает результат, обрабатывает его нужным образом, и передаёт в примитивный интерфейс гуя для прорисовки. Т.е. именно Presenter и является контроллером, а гуй(View) — придаток с простым интерфейсом, и по этой причине его легче заменять.
Что касается диалогов: согласитесь, ставить рядом, например, сложную рисовалку карт и диалог
с одной кнопкой выбора цвета — странно. Тем более, если диалогов много, они часто меняются, но
взаимодействуют с Presenter'ом через абстрактный интерфейс, который нужно подерживать.

А ссылки щас начну листать.

Re[2]: ModelPresenterView и служебные диалоги

	От:	shvonder
	Дата:	21.11.07 15:15
	Оценка:

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

S>Диалог останется диалогом, но на нем должен выводиться соответствующий контент т.е. реализация S>View, а Presenter отвечает только за формирование данных для отображения и не нужно его путать с S>контроллером ...

С этим, кстати, абсолютно согласен — диалог отображает состояние модели. Но как же не хочется его
делать отдельным View: интерфейс писать, реализацию интерфейса, создавать его где-то, регистрировать View<-->Presenter в друг друге, а потом ещё и управлять из Presenter'a: аля
IMyFamouseDlg10->ShowModal(). И всё через абстрактный интерфейс протаскивать. И ни боже мой не удалять из проекта — иначе убивать всё обратно..

Re[3]: ModelPresenterView и служебные диалоги

	От:	stenkil
	Дата:	21.11.07 16:56
	Оценка:

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

S> Что касается диалогов: согласитесь, ставить рядом, например, сложную рисовалку карт и диалог
S>с одной кнопкой выбора цвета — странно. Тем более, если диалогов много, они часто меняются, но
S>взаимодействуют с Presenter'ом через абстрактный интерфейс, который нужно подерживать.

S> А ссылки щас начну листать.

Если можна с этого места подробней, какая разница Presenter'у: это сложный диалог рисовалки или простенький диалог выбора цвета ?

Re[3]: ModelPresenterView и служебные диалоги

От:	Stormblast	http://www.myspace.com/stormblastblack
Дата:	22.11.07 08:10
Оценка:

Вообщем предлагаю тебе следующую схему:
есть Model которую слушает View в случае изменения модели View запрашивает новый Presenter который служит input-ом для данной View ...

упрощенно:
changeModel(...)
{
if(...){
view->setInput(...->getPresenter());
}
}

Re[4]: ModelPresenterView и служебные диалоги

От:	Stormblast	http://www.myspace.com/stormblastblack
Дата:	22.11.07 08:15
Оценка:

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

S>Вообщем предлагаю тебе следующую схему:
S>есть Model которую слушает View в случае изменения модели View запрашивает новый Presenter который служит input-ом для данной View ...

S>упрощенно:
S>changeModel(...)
S>{
S> if(...){
view->>setInput(...->getPresenter());
S> }
S>}

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

Re[5]: ModelPresenterView и служебные диалоги

От:	rsn81	http://rsn81.wordpress.com
Дата:	22.11.07 08:47
Оценка:

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

MVC != MVP
Вы говорите про MVC сейчас.

Re[6]: ModelPresenterView и служебные диалоги

От:	Stormblast	http://www.myspace.com/stormblastblack
Дата:	22.11.07 09:10
Оценка:

нет

Re[7]: ModelPresenterView и служебные диалоги

От:	rsn81	http://rsn81.wordpress.com
Дата:	22.11.07 09:17
Оценка:

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

S>нет
Зачем вам тогда активная модель в MVP?

Re[5]: ModelPresenterView и служебные диалоги

	От:	shvonder
	Дата:	22.11.07 09:34
	Оценка:

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

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

S>>Вообщем предлагаю тебе следующую схему:
S>>есть Model которую слушает View в случае изменения модели View запрашивает новый Presenter который служит input-ом для данной View ...
S>..
S>да забыл добавить:
S>после того как во View были внесены какие то данные то после сохранения они попадают сразу в модель естественно в данной схеме минуя Presenter, что вызовет событие обновление модели и т.д. ...

Я имею ввиду другой подход: когда логика полностью вынесена из View.
У тебя View сам запрашивает данные по событию от модели, сам отрисовывается по своей логике. Решили заменить View — нужно заново переписать всю логику рисования в новом View ( зато уж отрисовка будет оптимальной — View прекрасно знает, как себя лучше рисовать).
Я говорю о другом подходе: View реализует абстрактный интерфейс IView. Операции этого интерфейса
вызываются в Presenter'e. Хорошо то, что замена View никак не сказывается на логике рисования. Как вызывал Presenter абстрактные операции, скажем ICurveView,так и будет вызывать:

void Presenter::AfterCalculation()
{
m_curve_view -> DrawResult(...);
m_curve_view -> DrawMisfit(..);
}

То что реализация ICurveView* поменялась, он не в курсе. Смущает трудоёмкость:
все операции нужно протаскивать через интерфейс ICurveView. Если и диалоги тем же манером — просто вешалка

. И никакой, понимаешь, личной жизни

Re[8]: ModelPresenterView и служебные диалоги

От:	Stormblast	http://www.myspace.com/stormblastblack
Дата:	22.11.07 10:00
Оценка:

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

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

S>>нет
R>Зачем вам тогда активная модель в MVP?

что бы получить новый(измененный) Presenter.

Re[9]: ModelPresenterView и служебные диалоги

От:	rsn81	http://rsn81.wordpress.com
Дата:	22.11.07 10:04
Оценка:

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

S>что бы получить новый(измененный) Presenter.
А бывает такое, что вы более многословны?

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

Re[10]: ModelPresenterView и служебные диалоги

От:	Stormblast	http://www.myspace.com/stormblastblack
Дата:	22.11.07 13:55
Оценка:

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

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

S>>что бы получить новый(измененный) Presenter.
R>А бывает такое, что вы более многословны?

R>Насколько понял по написанному выше, модель у вас оповещает представление об изменении, по данному событию представление вытаскивает данные из предъявителя, пока правильно или нет?

да ... есть некий Builder который отдает Presenter ...

Re[11]: ModelPresenterView и служебные диалоги

	От:	shvonder
	Дата:	22.11.07 15:02
	Оценка:

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

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

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

S>>>что бы получить новый(измененный) Presenter.
R>>А бывает такое, что вы более многословны?

R>>Насколько понял по написанному выше, модель у вас оповещает представление об изменении, по данному событию представление вытаскивает данные из предъявителя, пока правильно или нет?

S>да ... есть некий Builder который отдает Presenter ...
Господа, ну не уклоняйтесь в сторону. Имеем модель неактивного Presenter'а, который ничего сам не делает, а только реализует интерфейс. Стоит ли для каждого диалога делать интерфейс, чтобы постредством него Presenter манипулировал ими наравне с остальными Presenter'ами ?

Re[12]: ModelPresenterView и служебные диалоги

	От:	shvonder
	Дата:	22.11.07 15:06
	Оценка:

S>постредством него Presenter манипулировал ими наравне с остальными Presenter'ами ?
ошибся, читать так:
"постредством него Presenter манипулировал ими наравне с остальными View'ами ?"

Re[11]: ModelPresenterView и служебные диалоги

От:	rsn81	http://rsn81.wordpress.com
Дата:	22.11.07 15:18
Оценка:

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

R>>Насколько понял по написанному выше, модель у вас оповещает представление об изменении, по данному событию представление вытаскивает данные из предъявителя, пока правильно или нет?
S>да ... есть некий Builder который отдает Presenter ...
Идем дальше. Представление определенным образом инициирует действия над моделью, которые отрабатывает предъявитель. Так зачем активная модель, если всеми манипуляциями над моделью занимается предъявитель, ведь после завершения своих действий он сам может оповестить представление?

Потому и говорю, что у вас явный MVC. В MVP модель и представление никоим образом не связаны, даже по Observer — попросту незачем. См., к примеру, здесь: Отличия от MVC — на приведенном там рисунке в вашем случае нужно нарисовать еще одну связь между представлением и моделью. См. там же рассмотрение гибридов MVC, возможно, у вас что-то вроде Supervising Controller, но вовсе не MVP.

1 2 >|

Переместить
Удалить
Выделить ветку

Пока на собственное сообщение не было ответов, его можно удалить.

Заголовок: