Certa 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 Caliburn.Micro para isso, e acabei implementando alguns conceitos MVVM sozinho (especificamente, apenas o ViewModelBase e RoutedCommand classes).
Agora fui designado para um projeto um pouco maior nas mesmas linhas: um ” Monousuário Aplicativo Rich Client Offline Desktop “, por assim dizer, e decidi usar Caliburn.Micro. E é aí que meu ” problema ” começa.
Eu li em esta famosa postagem do blog , cujo título diz que ” Se você” estiver usando MVVM, então precisa de uma estrutura “, que:
” Tentar fazer algo como MVVM sem uma estrutura é uma enorme quantidade de trabalho. Toneladas de código duplicado, reinventando a roda e treinando as pessoas de forma diferente .
Pelo menos com uma estrutura que você evita o código duplicado e, com sorte, não precisa reinventar a roda – permitindo que você se concentre em retreinar as pessoas. A parte do retreinamento geralmente é inevitável, mas uma estrutura fornece código e estrutura de encanamento, tornando o processo mais fácil. ”
Eu concordaria com a primeira leitura, mas minha experiência real com Caliburn.Micro (CM) na minha aplicação real está sendo de falta de noção e desorientação. Ou seja, a estrutura não tornou o processo mais fácil, muito pelo contrário. Ler os exemplos sempre repetidos fornecidos por Rob Eisenberg na documentação bastante (muito) informal e tentar inferir padrões de uso a partir das amostras fornecidas complicadas, e suas relações de classe e interface totalmente indiretas, onde as coisas parecem ser projetadas para funcionar com base nos efeitos colaterais, parecem humanamente impossíveis, 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 IoC, algo com que nunca trabalhei e que parece resolver um problema que talvez eu nem tenha . Não estou com vontade de gastar mais horas de projeto aprendendo essas coisas em vez de pensar no meu problema e nos domínios do 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 o meu framework MVVM caseiro – composto apenas de um punhado de MVVM- classes específicas que realmente desejo implementar – gostaria de pelo menos dar uma chance ao CM, caso esteja perdendo algo aqui ou simplesmente fazendo as coisas ” da maneira errada ” por pura inexperiência e ignorância. E então a pergunta é:
Há um consenso geral de que ” frameworks tornam as coisas mais fáceis e naturais “, mas se acontecer de eu estar experimentando exatamente o oposto, isso significa que não devo usar a estrutura ou que estou tentando aprender da maneira errada? Existe um pista de que eu nem deveria estar usando uma estrutura em primeiro lugar? Ou existe alguma forma ” certa ” de descobrir como usar o CM para desenvolvimento MVVM simples?
Comentários
Resposta
Eu tentei CaliburnMicro e MVVMLight e ao usar Caliburn, eu realmente sinto o que você sente, com certeza é realmente mágico poder vincular um controle a uma propriedade apenas usando Name = ” PropertyName ” em vez do antigo Text = ” {Bind PropertyName} “, mas no final Caliburn extrapola os limites para fazer essa coisa mágica . Quando algo dá errado, é muito difícil depurar e para piorar as coisas, eles têm várias maneiras de fazer uma coisa.
Em contraste, MVVMLight é muito fino. Quando você o usa, provavelmente percebe que é quase 100% parecido com o seu MVVM Framework, com alguns recursos espalhados nele.
Sei que isso não responde à sua pergunta ” Como NÃO usar o framework “, mas francamente, não posso recomendar que você siga esse caminho. Acho que você está perdido porque usou uma estrutura completa em vez de usar uma simples primeiro.
Comentários
- Você acha, então, que eu deveria pelo menos tentar usar MVVMLight como uma sorte de ” cure ” de ” Desorientação Caliburn.Micro “? Eu certamente daria uma olhada se for esse o caso.
- @heltonbiker Com certeza, experimente. É tão mais simples que deveria pelo menos dar a você uma boa base no MVVM Framework.
- Eu concordo que há muita mágica acontecendo. Vindo de um background de C e montagem, presumo. E algo não ‘ funcionou apenas para descobrir que funciona devido à magia no fundo. Impossível depurar e, quando você tem problemas de desempenho, geralmente não há muito o que fazer facilmente.
Resposta
É importante perceber o que é MVVM. Não é um bit compartilhado de 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 alguém pode escolher para implementar uma GUI rica. Portanto, se sua implementação do padrão é simples e direta, não acho que você precise sentir vergonha de usá-lo em vez de uma estrutura.
Na verdade, acredito que toda a ideia de padrões como estruturas foi longe demais. Para que qualquer coisa seja um padrão, deve ter a forma geral de uma classe de soluções. Por ser 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 único para todos. Seria muito mais construtivo deixar a implementação do padrão para o designer do aplicativo e fornecer bibliotecas que encapsulam a funcionalidade, em vez da arquitetura.
Comentários
- Adicionado a que o MVVM oferecido pela Microsoft (out of the box, WPF) está faltando muito. Muito frustrante até mesmo para programadores que pensam em si mesmos (e com razão) como desenvolvedores experientes. Strings mágicas, exceções obscuras em tempo de execução, coisas mais básicas, como vincular um grupo de botões de rádio a um enum, parecem stackoverflow.com/q/397556/168719 – o que que os frameworks podem fazer? Eles têm que ecoar esse nível de complexidade ou tentar fornecer uma abstração bem densa sobre ele
- @KonradMorawski WPF por si só não é MVVM; você pode fazer code behind com WPF, mas isso ‘ não é MVVM. Portanto, se você deseja fazer WPF e MVVM, ‘ precisará usar uma estrutura MVVM ou implementá-la você mesmo.
- @Andy, é claro, mas ‘ É seguro dizer que o WPF é destinado para MMVM.Eu ‘ m me referindo à funcionalidade MVVM que vem embutida com WPF. Eu sei que você ainda pode fazer código por trás
- @KonradMorawski Você pode usar WPF com MVVM, e eles o construíram com essa possibilidade em mente, mas NÃO há nenhuma funcionalidade específica do MVVM embutida no WPF. Assim como você pode usar MVP com WinForms, mas WinForms não oferece nada especificamente para usar esse padrão, cabe a você.
- @Andy talvez nós ‘ estamos discutindo sobre definições agora. O que quero dizer é que toda a ” cola ” que torna o MVVM possível já está lá – vinculações de dados em XAML,
DataContextetc.
Resposta
Minha primeira experiência com WPF foi usando Caliburn. Micro, então isso provavelmente é bem diferente da maioria dos desenvolvedores. Eu descobri que o WPF e o Caliburn.Micro são uma curva de aprendizado bastante íngreme, vindo 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 Caliburn.Micro não é usado, eu descobri que há MUITOS código de encanamento duplicado que torna a base de código bastante inchada e desnecessariamente complexa.
Eu definitivamente concordo que existem algumas pegadinhas com Caliburn.Micro, que pode complicar a depuração, no entanto, uma vez experimentados, é muito menos provável que sejam um problema novamente. A maior velocidade de desenvolvimento, o código mais limpo e enxuto e a estrutura geral encorajando um MVVM melhor valem a pena para mim.
Caliburn.Micro também não invalida WPF estoque – ele apenas se baseia nele, o que significa que você ainda pode usar recursos WPF se quiser e usar Caliburn para alguns bits e peças se quiser. Isso é semelhante a como TypeScript e JavaScript coexistem em minha mente.
Eu definitivamente usaria Caliburn.Micro em qualquer novo projeto WPF em que trabalhar no futuro, se tivesse a chance.
Comentários
- Obrigado pela sua resposta. Dois anos depois, achei muito mais fácil ” aceitar ” essas estruturas depois de compreender o conceito de Contêineres de injeção de dependência, que aprendi com o excelente Mark Seeman ‘ s ” DI em .NET ” livro.
Resposta
Para qualquer um que chega aqui frustrado com Caliburn.Micro, dê uma olhada neste framework: Estilete
É inspirado em Caliburn.Micro, exceto que remove muito da magia que deixa você desorientado sobre o que está acontecendo. Além disso, a documentação é escrita em uma linguagem muito mais simples, sem assumir que você deseja explorar o jargão técnico. Muito melhor para iniciantes.
Além disso, o Stylet usa uma abordagem ViewModel primeiro. Caliburn.Micro e muitos outros frameworks usam uma abordagem View-First, que vem com alguns problemas complicados. Se você já for muito bom em princípios SOLID e código padronizado, provavelmente achará uma abordagem ViewModel-First mais natural, pois considera que sua lógica deve conduzir o sistema – não a visualização.
EventAggregatorpara mensagens eNotificationObjectpara um ViewModelBase e MVVM Light ‘ sRelayCommandpara comandos. O importante é identificar quais problemas o framework vai resolver para você e usar apenas essas soluções. Não ‘ não sinta que ‘ é forçado a usar toda a biblioteca do framework.RelayCommandimplementação (uma vez que ” vincula ” diretamente a métodos por convenção, em vez de vincular a propriedades ICommand).RelayCommandde outra biblioteca se a usada pelo Caliburn Micro não funcionar para você.