Valor do MVVM em um aplicativo de linha de negócios (e um discurso retórico das práticas atuais de desenvolvimento)

Após 2 anos, ainda estou lutando com o MVVM como um método prático de produção de software funcional. Em alguns casos, é ótimo. Eu fiz um aplicativo multithread que controlava uma pequena linha de montagem que teria sido um pesadelo sem conceitos de MVVM. Uma abstração da linha de montagem física era quase um acéfalo.

No entanto, minha carreira gira principalmente em torno de aplicativos de linha de negócios internos - formalizando e otimizando as operações de um negócio. Nesses aplicativos, geralmente há um nível de negócios que gira em torno de operações CRUD e compostas. Nos LOBs, meus modelos de exibição acabam sendo uma coleção muito simples de funções de wrapper de uma linha dos métodos de classe de negócios e, no final, acabam complicando apenas as tarefas mais simples, como mostrar uma caixa de mensagem ou abrir uma janela. Ninguém mais acha estranho quando as pessoas fazem longas descrições de "injeção de dependência" e "provedores de mensagens" para uma chamada Window.ShowDialog que existe há décadas? Quantas outras perguntas existem no estouro de pilha solicitando conselhos para tarefas extremamente simples em winforms?

Não me interpretem mal - eu entendo o MVVM e como isso pode ser inestimável para grandes equipes que desenvolvem horizontalmente um pacote de software comercializado e compactado. O teste de unidade dos modelos de exibição poderia economizar milhões, evitando um erro incorreto da RTM, e os desenvolvedores dedicados da interface do usuário poderiam proporcionar uma experiência rica. Mas quando o custo de reimplementação é mínimo e todos os negócios que se preocupam em pagar por um software de trabalho simples, por que devo gastar tempo testando a unidade de um "wrapper" simples vm quando minha lógica de negócios já está testada? Quanto tempo o negócio realmente me permite gastar em animações fofas e esquemas de cores? Ainda resta algo a ser feito por um desenvolvedor júnior (rastrear um bug em uma funcionalidade de salvamento que costumava ver "Save_Click",

É certo que eu realmente gosto da ligação de dados do WPF. Para tirar proveito disso, defino o contexto dos dados para a própria janela, onde ele tem acesso à classe de negócios e a quaisquer outras propriedades observáveis. Sim, eu quebro quase todas as "regras" do MVVM ao fazer isso. Mas pelo menos eu tenho um código orientado a eventos simples que é fácil de ler E aproveito a nova ligação de dados e validação. O problema está nos designers - que eu não uso muito, mas espero que agora estejam melhor integrados em 2012 - o designer mostra as centenas de propriedades que uma janela e suas classes base têm.

Para aqueles que podem se relacionar, você pode me indicar recursos, livros ou mesmo apenas mudanças de perspectiva que tornaram isso mais fácil de engolir. Darei outra chance ao MVVM, mas na última vez em que me senti estúpido por me preocupar com injeção de dependência apenas para mostrar uma caixa de mensagem de uma VM, não tinha intenção de testar a unidade. Mesmo se eu fizesse o teste de unidade, estamos realmente obtendo mais qualidade negociando testes de tempo de execução para erros de tempo de compilação daqueles temidos aplicativos "fortemente acoplados"?

Sei que uma resposta é apenas ficar em winforms. Mas como um dos últimos apoiadores do WebForms (eu tenho a mesma crítica da tendência do desenvolvimento da Web), eu me senti um dinossauro como quando descobri que não havia mais WebForms nos trilhos de certificação da Microsoft. Seguir em frente é a única opção, mesmo que eu não goste.

Minha perspectiva é de anos de experiência trabalhando com o Winforms, o "caminho antiquado", com eventos e códigos por trás. Para que eu possa lhe dizer com certeza absoluta que, uma vez que você ultrapassa os aplicativos mais simples, seu código rapidamente se torna uma grande bola de barro . Era inevitável, porque era assim que os aplicativos eram escritos na época.

As formas da Web são exatamente iguais, exceto que isso gera a complicação adicional de ser uma abstração com estado em um sistema sem estado (a Web). Como Rob Conery colocou:

WebForms é uma mentira. É abstração envolto em engano coberto com molho mentiroso apresentado em um prato cheio de diversão e prestidigitação. Nada do que você faz com os Webforms tem algo a ver com a Web - você deixa que ela faça o trabalho para você.

Isso, do cara que escreveu um mapeador objeto-relacional totalmente funcional usando a dynamicpalavra - chave em C # e apenas quatrocentas linhas de código. Quando ele fala com autoridade sobre alguma coisa, eu ouço.

O aplicativo em que estou trabalhando atualmente é um aplicativo WinForms, com várias guias no formulário principal. Posso carregar dinamicamente formulários em cada uma das guias. Embora eu não tenha seguido o MVVM ou o MVP (você pode, com bibliotecas como esta ), fornei agressivamente todos os códigos possíveis para um assembly separado, deixando apenas o código absolutamente necessário para executar o formulário. Ainda existem várias centenas de linhas de código, sem contar a classe parcial que contém as definições de controle do formulário, as propriedades e as atribuições do manipulador de eventos, mas nunca precisarei tocá-lo novamente, a menos que precise adicionar algo novo ao formulário.

Eu tenho um método estático que eu posso entregar um formulário e uma coleção de pares Chave / Valor, e ele (usando o Reflection) combina automaticamente as chaves dos campos no formulário e preenche o formulário com os valores da coleção. Também posso fazer o inverso, obtendo uma coleção de pares Chave / Valor nos campos do formulário. Essa coisa toda tem cerca de vinte linhas de código, mas vale a pena toda vez que eu a uso, porque não preciso escrever quarenta instruções de atribuição personalizadas para quarenta controles em um formulário.

Eu posso pegar essa lista Chave / Valor e serializá-la em XML, permitindo que eu a persista em um arquivo. Tenho outros formulários nos quais posso entregar um DTO convencional e mapear seus campos para o formulário. Nada disso seria prático no estilo "grande bola de barro" do Winforms. É quase trivial quando o desacoplamento adequado é utilizado.

Isto soa familiar? Deveria; é essencialmente uma forma pobre de vinculação de dados.

É certo que eu realmente gosto da ligação de dados do WPF. Para tirar proveito disso, defino o contexto dos dados para a própria janela, onde ele tem acesso à classe de negócios e a quaisquer outras propriedades observáveis.

Bom para você. Não precisa ser compatível com MVVM. Mas lembre-se, padrões como o MVVM foram criados para ajudar os desenvolvedores a criar grandes sistemas. Se você só precisa exibir uma caixa de diálogo, pode não precisar de todo esse encanamento.

Parte da complexidade de sistemas como o WPF é inerente a todas as bibliotecas de programadores que buscam resolver um problema específico de maneira generalizada. Para fazer isso, você deve prestar contas de todas as maneiras práticas que um programador possa usar sua biblioteca. Isso aumenta a complexidade, mas para aqueles que projetam bem suas bibliotecas, também traz para a mesa uma filosofia de fazer as coisas de maneira uniforme e consistente.

Considere a biblioteca jQuery de John Resig: é a própria essência de um design coerente e oculta muitos detalhes estranhos sobre o DOM , além de variações na maneira como os navegadores o lidam. É mais simples escrever apenas algumas linhas de Javascript? As vezes. Mas o benefício de escrever o código jQuery em uma API uniforme e coerente facilita para a próxima pessoa que vem entender o que você fez e manter esse código, se necessário.

Minha experiência real com modelos de "grandes aplicativos" está no uso do ASP.NET MVC. O ASP.NET é para o ASP.NET MVC, como o WinForms é para o WPF. Quando eu trabalhava no ASP.NET, sempre lutava para dobrá-lo à minha vontade. O ASP.NET MVC se inclina para você. É uma alegria usar; produz uma estrutura de sistema clara e organizada e oferece controle total sobre seu aplicativo e marcação. Você pode usar Javascript, jQuery e CSS liberalmente, e o ASP.NET MVC fica fora do seu caminho.

Meu único obstáculo foi me acostumar com isso e conhecê-lo em seus próprios termos.

Leitura adicional,
você deve aprender MVC por Rob Conery