MVP e granularidade apresentador

Question

Estamos usando o padrão MVP e WinForms com uma quantidade razoável de sucesso. No entanto, uma pergunta sempre aparece-up sobre MVP:

O que é um boa granularidade para apresentadores?

O que quero dizer com isto é: Com Winforms, uma fina granularidade geralmente funciona muito bem para controles de usuário. Dessa forma, é fácil reutilizar controles de usuário e usá-los como blocos de construção, enquanto concepção de GUIs mais complexos. No entanto, tendo a mesma granularidade (bom-) com apresentadores parece ser um problema.

Por um lado, tendo grosseiro apresentadores dificulta a capacidade de usar "plug-in" controles e tipos de violar o princípio DRY: Vários apresentadores muitas vezes precisam de implementar a mesma lógica (populate uma lista de clientes, por exemplo), que é usado por vários, mais complexas, controles.

Por outro lado, refinado apresentadores parecem limitar a capacidade de controlo de reutilização em diferentes situações. Por exemplo, uma visão a edição pode às vezes precisa salvar o cliente de imediato; às vezes ele precisa vinculá-lo para outra coisa; às vezes é só precisa de validá-lo; e assim por diante. Muitas vezes, depende do controle mais complexo. Mas também há uma quantidade razoável de comportamento compartilhado.

Note-se que, em ambos os casos, 1-apresentador-1-view é realizável. O que é considerado "1-view" alterações.

O que é geralmente considerado melhores práticas para granularidade apresentador usando MVP e WinForms?

apresentadores
• refinadas e customizáveis ?? comportamento através de opções ou algo dessa natureza?
apresentadores e baixa capacidade de reutilização apresentador
• grosseiro?
• Algo mais?

Disclaimer: Nós usamos principalmente Supervising Controller, mas acho que também se aplica a Passive View. Desculpem a pergunta longa, também.

Answer 1

Nós usamos MVP em todos os nossos clientes e esta é definitivamente uma conversa que surge em mais de uma ocasião. Como limpa deve nosso código por trás de classes e apresentadores ser? Dito isto, optamos por usar a abordagem apresentador de grão grosso. Basicamente, toda forma teria seu próprio apresentador e só iria obter e definir propriedades de qualquer um dos controles em um formulário específico usando seu ponto de vista. Preencher controles de uma chamada para um db para preencher uma caixa de combinação, por exemplo, está localizada em uma classe de serviço público. Qualquer validação dos dados introduzidos usuário está localizado em uma classe BO que pode ser reutilizado por qualquer e / ou todos os apresentadores. Espero que isso ajude.

Answer 2

No meu sistema CAD-CAM meus apresentadores não usar controles de usuário. Controlos de utilizador reside na vista que residem em um EXE montagem que implementam as interfaces de vista da utilização apresentador.

Se pretender apresentar uma lista de clientes que entregá-lo à vista que tem uma DisplayCustomerList e usa qualquer combinação de controles de usuário que necessita para exibir a lista de clientes. Se vários pontos de vista mostrar a lista de clientes da mesma forma, em seguida, no EXE / Ver montagem eles compartilham um controle de usuário ou classe para fazer isso. Essa classe não ir para fora daquela assembléia.

O nosso software é adaptado para executar muitos tipos diferentes de máquina de corte de metal. Então nós colocamos muita ênfase em ser capaz de arrancar a interface do usuário e substituí-lo com uma interface de usuário completamente diferente (correspondendo a uma máquina diferente). Todas estas interfaces referenciar o mesmo conjunto de conjuntos centrais.

Os olhares de hierarquia como este

Ver EXE Apresentador Implementação Assembléia de comando - comandos são executados pelo apresentador que modificar o modelo Apresentador Interfaces Modelo Assembléias

Para o lado são conjuntos carregáveis ??que definem o conteúdo dinâmico como o que tipos de arquivos podem ser carregados, relatórios, corte drivers de dispositivo, etc. Estes implementar várias interfaces encontrados nas assembléias modelo

Uma coisa que eu faço é que eu não impelment uma vista do apresentador para cada diálogo. Se o diálogo está firmemente ligado com um comando, em seguida, ele é definido, criado e utilizado ao longo do lado da classe de comando. Ocasionalmente, um grupo de comandos relacionados irá partilhar um diálogo (manipulação de arquivos, por exemplo).

A questão essencial peço ao usar MVP é "O que acontece se deseja substituir completamente os formulários com outra coisa?". As respostas a essa pergunta vai identificar onde você está muito dependente de um determinado controle do usuário ou o motor formulário.

O maior problema (e que eu não tenho uma boa resposta para) da minha configuração é que IDEs e langauges atuais tornam muito fácil para amarrar controles de usuário para registros de banco de dados. É tão produtivo em relação qualquer outra configuração que tende a dominar o design. Eu não tive que lidar com a questão muito no meu aplicativo CAD-CAM, então eu não tenho nenhuma resposta diferente de passar o conjunto de dados para a vista e deixá-lo lidar com isso. Este site tem alguns padrões que podem ser de uso nesta situação.