Добрый день, хотел бы прояснить вопрос по презентерам в MVP.
Ситуация: два визуальных компонента (IView1, IView2), у каждого свои презентеры. Они размещаются на третьем компоненте (IView3). Пусть, например, View1 и View2 — комбобоксы, от которых приходит событие изменения активного значения. View3 должен получить измененные значения и на их основе выполнить некую операцию. Мне интересно, как лучше всего поступить:
View3 создает сам презентеры для View1 и View2, цепляется к их событиям, получает измененные данные и генерирует событие уже для своего презентера, который получает эти значения и на их основе уже производит изменения своего View3.
Либо: презентер для View3 создает сам презентеры View1 и View2 и подцепляет их. Но для этого IView3 должен вывести наружу свойства IView1 и IView2.
Или я вообще не тем путем иду?
Заранее благодарен!
... << RSDN@Home 1.2.0 alpha rev. 717>>
Здравствуйте, Legion13, Вы писали:
L>Либо: презентер для View3 создает сам презентеры View1 и View2 и подцепляет их. Но для этого IView3 должен вывести наружу свойства IView1 и IView2.
L>Или я вообще не тем путем иду?
Используем этот вариант. Хорош тем, что в частных случаях проще всю логику реализовать в Presenter3 не разбивая ее на Presenter1, Presenter2 и их взаимодействие.
... << RSDN@Home 1.2.0 alpha rev. 786>>
Здравствуйте, Ziaw, Вы писали:
Z>Используем этот вариант. Хорош тем, что в частных случаях проще всю логику реализовать в Presenter3 не разбивая ее на Presenter1, Presenter2 и их взаимодействие.
Спасибо, пока остановился тоже на нем, но не нравится явно выраженная зависимость IView3 от IView1 и IView2. Другой вариант тоже не нравится
... << RSDN@Home 1.2.0 alpha rev. 717>>
Здравствуйте, Legion13, Вы писали:
L>Здравствуйте, Ziaw, Вы писали:
Z>>Используем этот вариант. Хорош тем, что в частных случаях проще всю логику реализовать в Presenter3 не разбивая ее на Presenter1, Presenter2 и их взаимодействие.
L>Спасибо, пока остановился тоже на нем, но не нравится явно выраженная зависимость IView3 от IView1 и IView2. Другой вариант тоже не нравится
Явная зависимость от того, что на View3 лежат IView1 и IView2 а не IView3 и IView4?
Думаю она неизбежна, т.к. логика завязана них. Можно конечно выделить из каждой логику комбокса, но это овердизайн уже будет.
... << RSDN@Home 1.2.0 alpha rev. 786>>
L>View3 создает сам презентеры для View1 и View2, цепляется к их событиям, получает измененные данные и генерирует событие уже для своего презентера, который получает эти значения и на их основе уже производит изменения своего View3.
L>Либо: презентер для View3 создает сам презентеры View1 и View2 и подцепляет их. Но для этого IView3 должен вывести наружу свойства IView1 и IView2.
Доброго времени суток. По моему скромному мнению использовать нужно вариант 1, т.е.
презентер для View3 создает сам презентеры View1 и View2 и подцепляет их. Но для этого IView3 должен вывести наружу свойства IView1 и IView2.
Вариант 0
глубоко порочен, т.к. на мой взгляд View ничего не должен "знать" о презентерах, кроме как о своем собственном, конечно не может создавать презентеры, в том числе и для других View (про которые он впрочем не знает
). Страница View не является.
Насчет
не нравится явно выраженная зависимость IView3 от IView1 и IView2
— а что собственно не нравится ? С точки зрения семантики и ответственности никаких противоречий я считаю не имеется.
Использую такой подход успешно.
Например если бы у меня на странице лежал контрол Control3 который реализует IView3
то код был бы таким:
private IPresenter3 _presenter;
protected void Page_Load(object sender, EventArgs e)
{
//некий код
if(!IsPostBack)
{
_presenter.InitView();
}
}
"некий код" == _presenter интанцируется через IoC, потом инициализируется. в качестве IView3 ему прописывается Control3.
в IPresenter3 есть свойства для IPresenter1 и IPresenter2 — аналогично внутри Presenter3 инстанцируются
презентеры для этих свойств, которым в качестве отображений прописываются IView1 и IView2 которые берутся из свойств IView3.
В качестве подопытного у меня в основном выступает контрол для работы с самописной вики.
Который соответственно может входить в состав других контролов.
Инициализация презентера для контрола который содержит в себе вики-контрол выглядит так:
private INWikiPresenter _nWikiPresenter;
public INWikiPresenter NWikiPresenter
{
get { return _nWikiPresenter; }
private set { _nWikiPresenter = value; }
}
public InitMe(IQuestionView view, Guid questionUID, IStateStorage stateStorage)
{
AttachView(view);
View.AttachPresenter(this);
StateStorage = stateStorage;
//некий код
NWikiPresenter.InitMe(view.NWikiView, Question.DocumentUID);
NWikiPresenter.AfterSaveInTransaction += OnNWikiAfterSaveInTransaction;
NWikiPresenter.DocumentEdit += OnNWikiEdit;
NWikiPresenter.Cancelled += OnNWikiCancelled;
NWikiPresenter.DocumentSaved += OnNWikiSaved;
}
О событиях которые выше: например для контрола который подопытный метод презентера для сохранения вики-документа выглядит так:
public void SaveDocument(string body, string comment)
{
using (TransactionScope scope = new TransactionScope())
{
RaiseEvent(BeforeSaveInTransaction);
Document.Save(body, comment);
RaiseEvent(AfterSaveInTransaction);
scope.Complete();
}
RaiseEvent(DocumentSaved);
if (StateStorage != null)
{
StateStorage.Write(Document.NWikiGuid, UniformKeys.DocumentUID);
}
Document.LoadHtml();
SetEditMode(false);
}
(здесь Document это свойство-сущность (грубо говоря), StateStorage — просто хранитель состояния куда можно сохранять данные. Например в презентер прописываю просто ViewState соответствующего контрола.)
