Model-View-Presenter и перенос больших объектов - PullRequest
Новая
       31

Model-View-Presenter и перенос больших объектов

0 голосов
/ 11 августа 2010

Я традиционно реализовал Model-View-Presenter [Passive View] примерно так: 

interface IView
{
string Title {set;}
}

class frmTextBox : Form, IView
{
...
public string Title
{
set { this.txtTitle.Text = value; }
}
...
}


class frmLabel : Form, IView
{
...
public string Title
{
set { this.lblTitle.Text = value; }
}
...
}

class Presenter
{
private IView view;
...
public void UpdateTitle
{
this.view.Title = "A Good Title";
}
...
}

, и я традиционно использовал только примитивные типы в интерфейсе IView (int, string, bool) потому что я всегда понимал, что вам нужно использовать примитивные типы только в представлении.В репозитории (например, NHibernate), если я хочу отобразить список элементов в DataGridView, я должен передать общую коллекцию (IList<T>) из модели в Presenter.Нарушает ли это правило, лежащее в основе представлений, состоящее только из примитивных типов, или это будет архитектурно нормально?

Даже если бы у меня был объект передачи данных (DTO), это был бы скорее контролирующий контроллер, чем стиль пассивного представления, который я пытаюсь реализовать.

Мысли ??

Ответы [ 2 ]

2 голосов
/ 11 августа 2010

Существуют шаблоны, которые помогут вам разработать решение на основе опыта других.

Это не более чем формализованные шаблоны.

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

2 голосов
/ 11 августа 2010

Ух ты, может быть, я многое упустил.Я никогда не видел, чтобы представления были ограничены только отображением примитивных типов.

Мне было бы интересно узнать, почему используется это ограничение и в чем его преимущество?Это не значит, что «ИМО, это совершенно неправильно», но мне любопытно, что это за преимущества.Я считаю, что компьютеры сейчас достаточно мощные, и если вы не нацелены на конкретную спецификацию производительности, то затраты разработчика на адаптацию к определенному руководству будут дорогостоящим использованием ресурсов.,но все статьи MVC, которые я видел, счастливо объединяли классы между представлением и контроллером.Поскольку MVP - это просто другая форма MVC, я бы сказал, если это не проблема с MVC, должна ли она быть с MVP?

...