Como escolher NÃO usar uma estrutura (Caliburn.Micro, etc.) em um determinado aplicativo MVVM?

Uma vez, iniciei um projeto MVVM / WPF, que acabou sendo construído e implantado, e para isso estudei muito o Caliburn.Micro MVVM Framework. O fato é: acabei não usando o Caliburn.Micro para isso e acabei implementando alguns conceitos do MVVM (especificamente, apenas as classes ViewModelBasee RoutedCommand).

Agora, fui designado para um projeto um pouco maior nas mesmas linhas: um "Aplicativo de desktop offline de cliente único e rico para clientes", por assim dizer, e decidi usar o Caliburn.Micro. E é aí que o meu "problema" começa.

Eu li neste famoso post no blog , cujo título diz que "Se você estiver usando o MVVM, precisará de uma estrutura", que:

"Tentar fazer algo como o MVVM sem uma estrutura é uma enorme quantidade de trabalho. Toneladas de código duplicado, reinventar a roda e treinar novamente as pessoas para pensarem de maneira diferente .

Pelo menos com uma estrutura, você evita o código duplicado e, esperançosamente, não precisa reinventar a roda - permitindo que você se concentre em treinar as pessoas. A parte de reciclagem é geralmente inevitável, mas uma estrutura fornece código e estrutura de encanamento, facilitando o processo. "

Eu concordaria com a primeira leitura, mas minha experiência real com Caliburn.Micro (CM) em minha aplicação atual é de falta de noção e desorientação. Ou seja, a estrutura não facilitou o processo, muito pelo contrário. Lendo os exemplos sempre repetidos fornecidos por Rob Eisenberg na documentação informal (também) informal e tentando inferir padrões de uso a partir das amostras complicadas fornecidas e de seus relacionamentos de classe e interface totalmente indiretos, nos quais as coisas parecem ter sido projetadas para funcionar com base em efeitos colaterais, parece humanamente impossível, a menos que você seja um gênio experiente (desculpe o discurso retórico, mas acho que você sabe o que quero dizer).

Sem mencionar que qualquer cenário acima do trivial parece envolver contêineres de IoC, algo com o qual nunca trabalhei e que parece resolver um problema que talvez nem tenha . Não me apetece passar mais horas do projeto aprendendo essas coisas, em vez de pensar nos meus problemas e domínios de aplicativo. Eu só queria uma banana, mas CM me deu um gorila (IoC) segurando uma cesta de bananas.

Agora que estou pensando em voltar para minha estrutura MVVM caseira - composta apenas por algumas classes específicas de MVVM que realmente quero implementar -, gostaria de pelo menos dar uma chance ao CM, caso esteja perdendo algo aqui, ou simplesmente fazendo as coisas "do jeito errado" por pura inexperiência e ignorância. E então a questão é:

Há um consenso generalizado de que "estruturas tornam as coisas mais fáceis e mais naturais", mas se eu estiver enfrentando o contrário, isso significa que não devo usar a estrutura ou que estou tentando aprender da maneira errada? Existe uma pista de que eu nem deveria estar usando uma estrutura em primeiro lugar? Ou existe alguma maneira "certa" de descobrir como usar o CM para o desenvolvimento simples do MVVM?

Eu tentei o CaliburnMicro e o MVVMLight e, ao usar o Caliburn, realmente sinto o que você sente, com certeza é realmente capaz de vincular o controle à propriedade usando Name = "PropertyName" em vez do antigo Text = "{Bind PropertyName}", mas no No final, Caliburn se esforça demais para fazer essa coisa mágica; quando algo dá errado, é realmente difícil depurar, para piorar as coisas, elas têm muitas maneiras de fazer uma coisa.

Porém, ao usar o MVVMLight, ele é fino; quando você o utiliza, provavelmente percebe que ele é quase 100% parecido com o MVVM Framework, com alguns recursos espalhados nele.

Sei que isso não responde à sua pergunta "Como NÃO usar a estrutura", mas sinceramente não posso recomendar que você siga esse caminho porque está errado, também acho que você está perdido porque usa a estrutura com recursos completos em vez de usar a simples um primeiro.

É importante perceber o que é MVVM. Não é uma parte compartilhada da funcionalidade que você não precisa reimplementar (analisando um arquivo JPEG ou conectando-se a um determinado servidor de banco de dados SQL); é um padrão - um padrão de como se pode optar por implementar uma GUI avançada. Portanto, se sua implementação do padrão for simples e direta, não acho que você precise sentir vergonha de usá-lo, e não uma estrutura.

Na verdade, acredito que toda a idéia de padrões como estruturas foi longe demais. Para que qualquer coisa seja um padrão, ela deve ter a forma geral de uma classe de soluções. Como é assim, é de se esperar que os padrões precisem ser adaptados aos sistemas que os utilizam e você não poderá fazer isso se tentar usar um padrão de tamanho único. Seria muito mais construtivo deixar a implementação de padrões para o designer de aplicativos e fornecer bibliotecas que encapsulam funcionalidade, em vez de arquitetura.

Minha primeira experiência com o WPF foi usando o Caliburn.Micro, portanto isso provavelmente é bem diferente da maioria dos desenvolvedores. Eu encontrei o WPF e o Caliburn.Micro como uma curva de aprendizado bastante acentuada, proveniente do WinForms, no entanto, depois de alguma experiência com ambos, achei um prazer usá-los como um par. Atualmente trabalhando em uma organização diferente onde o Caliburn.Micro não é usado, acho que há MUITO código de encanamento duplicado, o que torna a base de código bastante inchada e desnecessariamente complexa.

Definitivamente, concordo que há algumas dicas com o Caliburn.Micro, que podem complicar a depuração, no entanto, uma vez experimentadas, é muito menos provável que sejam uma dor novamente. O aumento da velocidade de desenvolvimento, o código mais limpo e enxuto e a estrutura geral que incentiva uma MVVM melhor valem a pena para mim.

O Caliburn.Micro também não invalida o WPF de estoque - ele apenas é construído sobre ele, o que significa que você ainda pode usar os recursos do WPF se quiser e usar o Caliburn por alguns bits, se quiser. Isso é semelhante a como o TypeScript e o JavaScript coexistem juntos em minha mente.

Definitivamente, eu usaria o Caliburn.Micro em qualquer novo projeto do WPF em que trabalho no futuro, se tiver a chance.

Para quem chega aqui por frustração com o Caliburn.Micro, dê uma olhada nesta estrutura: Stylet

É inspirado no Caliburn.Micro, exceto que remove muita magia que o deixa desorientado com o que está acontecendo. Além disso, a documentação é escrita em uma linguagem muito mais clara, sem assumir que você deseja percorrer o jargão técnico. Muito melhor para iniciantes.

Além disso, o Stylet adota uma abordagem ViewModel-First. O Caliburn.Micro e muitas outras estruturas adotam uma abordagem View-First, que vem com alguns problemas embaraçosos. Se você já é muito bom em princípios e código padronizado do SOLID, provavelmente encontrará uma abordagem ViewModel-First mais natural, pois leva a perspectiva de que sua lógica deve conduzir o sistema - não a visão.