MVP: сторонние элементы управления, сколько логики можно поместить в слой View - PullRequest
0 голосов
/ 29 декабря 2010

Я изучаю паттерн MVP, но все еще сомневаюсь.

Мартин Хантер в своем обзоре MVC / MVP писал:

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

(...)

Однако в MVP представление ловитсобытия генерируются и направляются к контроллеру (докладчику)

Это нормально с кнопками и текстовыми полями, но что в случае более сложных элементов управления?Допустим, я использую сторонние компоненты, такие как элемент управления Devexpress TreeList.Предположим, я хочу динамически строить подузлы, когда пользователь нажимает кнопку «+».Не используя какой-либо шаблон, я мог бы написать такой код:

private void BeforeExpand_EventHandler(object sender, BeforeExpandEventArgs e)
{
    TreeList treeList = sender as TreeList;
    MyModelObject nodeObj = e.Node.Tag as MyModelObject;

    treeList.BeginUnboundLoad();

    //Create sub-nodes depending on nodeObj 

    treeList.EndUnboundLoad();
}

Как вы можете видеть, есть некоторые объекты View, такие как BeforeExpandEventArgs, TreeListNode, некоторые конкретные действия, такие как BeginUnboundLoad () и так далее.В этом случае мой слой View не может быть «ультратонким».Я не могу напрямую перейти к объектам Presenter, таким как BeforeExpandEventArgs, потому что это повлияет на Presenter с некоторыми элементами View.

Мой вопрос: Сколько логики я могу поместить в слой View ?Например, представлен ли код ниже нормально?

private void BeforeExpand_EventHandler(object sender, BeforeExpandEventArgs e)
{
    TreeList treeList = sender as TreeList;
    MyModelObject nodeObj = e.Node.Tag as MyModelObject;

    treeList.BeginUnboundLoad();

    e.Node.Nodes = this.presenter.GetNodes(nodeObj);

    treeList.EndUnboundLoad();
}

1 Ответ

0 голосов
/ 29 декабря 2010
  1. Я думаю, что View отвечает за решение этой проблемы. Идея MVP (MVC) заключается в том, что вы можете переключаться на другой View, не меняя Model & Presenter хотя бы теоретически;). Так что логика просмотра может остаться на уровне просмотра, как вы.
  2. Одна вещь, с которой я не согласен в вашем образце, это ссылка на докладчика. Вы должны сделать обратное. Презентатор должен иметь ссылку на просмотр, а также объекты модели. В этом случае View вызывает свое событие, которое Presenter уже прослушал, а Presenter возвращает массив узлов в View.
...