Abordagem para a construção de modelos de visualização no aplicativo MVVM complexo

Question

Abordagem para a construção de modelos de visualização no aplicativo MVVM complexo

#1 resposta do (2 votos)

5

Estou lutando com o design em um aplicativo WPF MVVM. Em alguns cursos que fiz, eles dizem que ter muitos parâmetros em um construtor é um cheiro de código, mas eles nunca abordam como lidar com isso.

Em um projeto recente meu, usamos injeção de dependência para fornecer serviços que seguem um padrão de adaptador de dados. Cada uma dessas classes é focada em um tipo, como fornecedor, funcionário, detalhes, cotação, solicitação de cotação etc.

Neste aplicativo, os modelos de visualização de alto nível não fazem muito, mas eles hospedam vários modelos de visualização, como: detalhes, anexos de arquivos, notas, seleção de fornecedores e requisitos do fornecedor. O construtor para o modelo de visualização de detalhes não processados usa quase todos os serviços em seu construtor, mas usa apenas esses parâmetros para construir seus modelos de visão filho.

Não faz sentido que o modelo de vista principal conheça um modelo de vista de detalhe, porque o modelo de vista principal é responsável apenas pela navegação de nível superior. Então qual abordagem pode ser usada para compor os modelos de visão de alto nível sem muitos parâmetros de construtor, ou não é uma má prática neste caso, porque os modelos de visão de alto nível são responsáveis por compor os modelos de visão de baixo nível?

design-patterns constructors factory mvvm builder-pattern

por Adam 17.08.2018 / 14:58

fonte

1 resposta

Tags design-patterns constructors factory mvvm builder-pattern

Vale a pena implementar o Entity Framework ao chamar um único select armazenado? Quais são os desafios na criação de um aplicativo da web escalonável em tempo real?

score 2 · Answer 1

Nossa equipe teve o mesmo problema com modelos de visualização na estrutura do ASP.NET MVC. A composição da hierarquia de visualizações começou a se tornar complexa e, à medida que a interface do usuário evoluiu, tivemos que fazer mudanças cada vez mais altas na estrutura do modelo de visualização e, depois, propagar essas alterações mais adiante e mais adiante passando argumentos de construtor.

Nós percebemos que um modelo de exibição representando uma página da Web inteira realmente precisava de muitas informações de várias fontes. Mesmo assim, conseguimos reutilizar os modelos de visualização em vários contextos, mas configuramos apenas um pouco diferente.

Cheguei à conclusão de que esses modelos de visualização de "nível superior" realmente representavam um caso de uso no aplicativo e tinham necessidades de inicialização diferentes dos modelos de exibição que representavam partes de uma página da Web - componentes individuais.

Introduzimos os objetos de fábrica do modelo de exibição que se especializaram na inicialização dos modelos de exibição complexos. Modelos de exibição que representavam um único componente na tela tinham menos dependências e pudemos continuar a inicializá-los por meio de parâmetros de construtor.

Não havia uma linha clara que se cruzasse onde dissemos "precisamos de uma fábrica de modelos". Tornou-se um pressentimento. Quando a inicialização de um modelo de visão se torna complexa, nós movemos a lógica de inicialização para um método de fábrica, mas a inicialização dos modelos de visão continua sendo responsabilidade dos construtores de cada modelo de visão até chegarmos a esse ponto.