MVP e UserControls e invocação

Question

Eu estou tendo um pouco de diversão tentando obter minha cabeça em torno de alguns stuf MVP, no que tange a controles de usuário. Eu estou usando WinForms NET (ou algo próximo a ela) e supervisão padrão Controller (bem, eu penso que eu sou :).

O User Control é em si parte de um aplicativo MVP (o seu modo de exibição e tem um Apresentador associados etc). O Presenter é sempre iniciado pela primeira vez, e ele começa a Modelo (s) e, em seguida, View (s). The View constrói sua UI, parte do qual será NOVO do UC, que é o View.

Agora, a (forma) Apresentador precisa saber sobre a UC Presenter, mas estou pensando que ele não sabe nada sobre como a vista é composta. A forma Apresentador não, por exemplo, sabemos que a UC é parte da coleção Controls do formulário, nem deve.

Além disso, a experiência em design não deve ser alterado; IOW o dev do Vista (formulário) deve apenas ser capaz de selecionar um Usuário de Controle da caixa de ferramentas e solte-o em um formulário.

Assim, para as minhas perguntas. Em primeiro lugar, são as minhas premissas acima correto? Um pouco equivocada? Bagunçado? WTF você está pensando?

Em segundo lugar, é certo (o suficiente?) Ter a forma de exibição invocar a UC View, ea forma Apresentador invocar a UC Apresentador e ter algum mecanismo para contar a UC Ver o seu Presenter é? Isso quebra meu "Apresentador primeira" regra, mas eu não tenho certeza que outra forma de fazê-lo.

Quaisquer outros pensamentos, sugestões, comentários aceitou de bom grado.

- nwahmaet

Answer 1

Um apresentador deve ser pensado como "estado autônomo" na camada de apresentação. Isso significa que ele é responsável por assegurar que a exposição da vista do estado do modelo está em sincronia. A razão que eu trago este acima é porque o "padrão" de MVP muitas vezes se perde na visão dogmática de como as coisas devem ser separadas. Parece que esta é uma das razões Martin Fowler decidiu tentar esclarecer a terminologia em todo o MVP padrão.

O meu sabor preferido de MVP é o passiva vista , por isso a minha resposta é baseado fora dessa .

Eu implementar controles de usuário compostos e formas, muitas vezes usando o padrão vista passiva. Existem essencialmente 3 configurações diferentes:

1. Um apresentador para todos os controles de usuário na hierarquia. Achatar a vista usando uma interface.
2. Um apresentador para cada controle de usuário na árvore composta. Cada apresentador pai é responsável por instanciar e inicializar seus apresentadores criança. Os controles de usuário são criadas em tempo de design, e são capazes de funcionar sem um apresentador (sem comportamento apresentação)
3. Um apresentador para cada controle de usuário na árvore composta. Todos os apresentadores são fracamente acoplada através de uma classe controlador de nível superior. A classe controlador é responsável por construcing o apresentador, fiação-los para cima, e coordenar os seus eventos.

Apesar de ser uma solução de último recurso para mim (por causa de sua complexidade), eu acho que a última opção é a solução que você está procurando.

Answer 2

Fui correndo contra este problema exato durante vários meses em um aplicativo que estou trabalhando. A conclusão que eu vim muito recentemente é que em muitos casos, pode ser impossível aplicar o padrão MVP, tanto a nível de janela e controle do usuário, sem "quebrar" o padrão.

O meu pensamento sobre ele é que o controle de usuário é parte da implementação vista, eo apresentador não deve saber o que está acontecendo dentro da implementação ponto de vista, o que significa que o apresentador de nível janela por extensão não deve saber sobre o usuário apresentador de controlo, e, portanto, não deve haver comunicação entre eles, incluindo instanciação destes últimos pelo antigo. Pode-se argumentar que o apresentador do controle do usuário é parte da implementação vista da janela, e para que a vista da janela pode instanciar o apresentador controle do usuário. Mas ele não pode injetar as classes do modelo que as necessidades do apresentador, porque a vista não é suposto estar ciente delas.

A conclusão que eu acho que estou chegando é que os controles utilizador Todas são específicos vista-implementação-e assim deve ser contido completamente dentro da vista silo do padrão maior. Como tal, eles não começa a ter seus próprios apresentadores ... Pelo menos não empacotados com a própria implementação de controle. Em vez disso, deve ser manipulado indiretamente pelo apresentador da janela pai, via repasse campos expostos na interface de visualização. Em suma, o controle de usuário é exposto para o apresentador não pela sua própria interface, mas sim através de um comum pass-through interface implementada pela sua vista principal. Chamam isso de "interface de visão parcial".

O apresentador pode então conter instâncias de uma classe sub-apresentador re-utilizáveis ??que funciona apenas com esta interface visão parcial, e as peças relevantes do modelo. Isso permitirá que você para evitar a re-escrever o código apresentador de tradução do modelo de cada vez que você precisa usar o controle, e isso impede que a vista da janela da necessidade de saber sobre o modelo a fim de passar informações através de apresentador do controle.

O que isso efetivamente faz é que separa ainda mais o controle do usuário, como um módulo, a partir de seu modelo de dados. Isso faz sentido se você pensar em um controle de usuário, como um todo, como um elemento da implementação vista. Como uma unidade de re-utilizáveis, é um pedaço de funcionalidade vista, e nenhuma parte dele deve ser amarrado ao seu modelo de dados.

Answer 3

As suas perguntas é geral que uma variedade de esquemas poderia aplicar-se.

Neste caso, o meu palpite é que você deve olhar para Pattern Observer.

Você tem uma interface que qualquer coisa que usa esse ponto de vista seria implementar. Em seguida, ele iria registar-se quando o aplicativo é inicializado com uma coleção dessas interfaces. Qualquer comando que precisa atualizar essa visão iria percorrer a coleção notificando que cada vista devem ser actualizados.

exemplos típicos Ao contrário dos pontos de vista seria User Controls. Você tem a flexibilidade de fazer qualquer elemento UI implementar essa interface para que você possa usar diálogos, formulários completos, etc, além de seu User Control.

Finalmente lembre-se o usuário controle não é a vista, mas a implementação da Visão. Seja qual for o esquema que você adotar você pode definir o que a vista tão profundo como você quer e tem o User Control implementar essa interface.