MVP / MVC vs abordagem tradicional n-tier para aplicativos winform
-
09-09-2019 - |
Pergunta
Temos uma grande suíte de aplicativos, a maioria são C # 1.1, mas pelo menos 10 principais são em VB6. Estamos realizando um projeto para abrir os aplicativos VB6 para .NET 3.5.
Todo o c # 1.1 aplicações são escritas usando uma abordagem tradicional n-Tier. Não há realmente qualquer arquitetura / separação para a camada de interface do usuário. A maioria do código apenas responde a eventos e vai de lá. Eu diria que, do ponto de manutenção, tem sido muito bom e é fácil de seguir código e chegar até a velocidade em novas aplicações.
Como estamos portar aplicativos VB6, o pensamento inicial foi que devemos manter o padrão existente (por exemplo n-Tier).
Eu estou querendo saber, se vale a pena quebrar o padrão e fazer aplicativos VB6 usando teh padrão MVP / MVC? São MVC / MVP aplicativos winform realmente mais fácil de manter? Eu trabalhei em um projeto baseado em MVC e não senti que era mais fácil de manter em tudo, mas isso é apenas um projeto.
O que são algumas das experiências e conselhos lá fora?
Solução
Cara, se algo funciona para você, vocês são confortáveis ??com ele, e sua equipe é até especificações com ele. Por que você precisa mudar?
MVC / MVP soa bem ... Então, por que eu ainda estou trabalhando em n-Tier-me?
Eu acho que antes de se comprometer recursos para o desenvolvimento real sobre esta nova forma de programação ... Você deve considerar se ele funciona para a sua equipe.
Outras dicas
Se estiver portando os aplicativos VB6 contra uma reescrita completa, eu sugiro para se concentrar no seu objetivo Pri 1 - para obter o mais cedo possível para o mundo .Net. Apenas fazendo isso teria um monte de benefícios para o seu org.
Uma vez que você está lá, você pode avaliar se é benéfico para você investir em rearquitetar esses aplicativos.
Se você está fazendo reescrita completa, eu diria que tomar a mergulhar e ir para MVP / MVVM modelada aplicativos WPF. WPF willl dar-lhe visuais mais agradáveis. O padrão MVP / MVVM lhe dará unidade testability para todas as camadas, incluindo o visual. Presumo também que esses aplicativos estão relacionados, então as chances são que você pode ser capaz de realmente reutilizar seus modelos e pontos de vista. (Embora, eu poderia estar errado aqui)
Ele move uma fina camada de código que você provavelmente ainda tem na UI. Eu digo fina, porque a partir de sua descrição, você provavelmente tem uma abundância de outros lugares código. O que isso lhe dá é a capacidade de teste de unidade que fina camada de código.
Update 1: Eu não recomendo para arquitetar re ao fazer o upgrade, o esforço extra é melhor expend em começar testes automatizados (unidade / integração / sistema) - desde que você terá que ser testando as obras de actualização de qualquer maneira. Depois de ter os testes no lugar, você pode fazer mudanças graduais para a aplicação com o conforto de ter provas para apoiar as mudanças.
MVC em particular não exclui arquitetura n-tier.
Temos também ASP.NET 1.1 aplicativo de negócios, e acho que é um pesadelo real para manter. Quando manipuladores de eventos fazer o que quiserem, talvez ajustar outros controles, talvez chamada algo em lógica de negócios, talvez falar diretamente com o banco de dados, é apenas por acaso que o software funciona em todos.
Com MVC, se usado corretamente, você pode ver a forma como os fluxos de dados a partir do banco de dados para a interface do usuário e para trás. Ela torna mais fácil para controlar os erros se você tem o comportamento inesperado.
Pelo menos, é assim com o meu próprio projeto pouco.
Eu vou fazer o ponto mais uma vez: qualquer padrão que você usa, vara para a arquitetura n-Tier clara. 2-Tier ou 3-Tier, apenas não suja tudo em uma grande bola interligados.
"Change - que a atividade nos envolvemos em dar a alusão do progresso". - Dilbert
Falando sério, ficando apenas o seu ambiente de desenvolvimento e plataformas de implantação até .NET 3.51 é um grande passo em si. Eu recomendaria que coisas como revisões de segurança e código de instruções passo a passo provavelmente deve vir antes archecting re-aplicação.
MVC e MVVM são excelentes paradimes, particularmente em termos de capacidade de teste. Não se esqueça sobre eles, mas talvez você deve considerar um projeto piloto antes da adopção em grande escala?