Модель-вид-ведущий и передача больших объектов

Question

У меня традиционно реализовано представитель моделей [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>) от модели до ведущего. Это нарушает правило позади взглядов, состоящих только из примитивных типов или это архитектурно будет в порядке?

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

Мысли??

Answer 1

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

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

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

Answer 2

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

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

Не то, что это какое-то одобрение как таковых. Но все статьи MVC, которые я видел, были счастливо связаны вокруг классов между видом и контроллером. Поскольку MVP - это просто другая форма MVC, я бы сказал, если это не проблема с MVC, если она должна быть с MVP?