Model-View-apresentador e transferindo objetos grandes

Question

Tradicionalmente, implementei uma visualização-visualização do modelo [Vista passiva] como assim:

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";
}
...
}

e eu tradicionalmente só usava tipos primitivos no IView interface (int, string, bool) porque eu sempre entendi que você precisa usar tipos primitivos apenas na visualização. Em um repositório (como NHibernate), se eu quiser exibir uma lista de itens em um DataGridView, Eu tenho que passar uma coleção genérica (IList<T>) do modelo ao apresentador. Isso viola a regra por trás das visões como consistindo apenas de tipos primitivos ou isso seria arquiteturalmente ok?

Mesmo se eu tivesse um objeto de transferência de dados (DTO), isso seria mais um controlador supervisor do que no estilo de visão passivo que estou tentando implementar.

Pensamentos??

Answer 1

Existem padrões para ajudá -lo a projetar sua solução com base nas experiências de outras pessoas.

Eles nada mais são do que modelos formalizados.

Use qualquer estrutura que o torne mais produtivo, mesmo que não se encaixe perfeitamente em uma definição arbitrária.

Answer 2

Uau, talvez eu tenha perdido muito. Eu nunca vi visualizações como limitadas a exibir apenas tipos primitivos.

Eu estaria interessado em saber por que essa restrição é usada e qual é o benefício disso? Isso não quer dizer que "IMO está totalmente errado", mas estou curioso para saber seus benefícios. Minha crença é que os computadores são suficientemente poderosos agora que, a menos que você esteja visando uma especificação de desempenho específica, o custo de um desenvolvedor martelando para se adequar a algumas diretrizes seria um uso caro dos recursos.

Não que seja qualquer endosso em si. Mas todos os artigos do MVC que eu vi estão felizes em torno de classes entre a vista e o controlador. Como o MVP é apenas uma forma diferente de MVC, eu diria que se não for um problema com o MVC deveria estar com o MVP?