Aplicação de WPF, MVVM e Prism
195 views
Skip to first unread message
Secco
Jan 5, 2012, 2:32:01 PM1/5/12
to .Net Architects
Boa tarde pessoal.
Estamos, em nossa equipe, estudando a possibilidade da utilização de
WPF com Prism.
Nossa solução atual foi criada com a utilização de Windows Forms,
portanto há uma série de fatores que devemos considerar e estudar para
atingir de forma satisfatória os objetivos desta migração.
Dentre as novas características que estão ligadas a estas tecnologias,
está o MVVM Pattern. Este utiliza um conceito um tanto diferente do
que normalmente encontramos por aí e conhecemos.
Apesar de estarmos lendo bastante sobre o padrão, não conseguimos
definir se sua utilização ("puristamente" falando) será realmente
produtiva para nosso propósito, que é a criação de um sistema que
possuirá um número bastante elevado de telas de cadastro (CRUD).
Até onde entendemos, a utilização do padrão causa, por exemplo, um
certo retrabalho na definição dos Models, que devem ser "recriados"
nos ViewModels. Pelo menos é o que temos absorvido das literaturas.
Gostaria de saber se alguém tem algum relato de experiência ou dica
que possa nos guiar a respeito da utilização destas tecnologias.
Abraços.
Diego Stiehl
Estamos, em nossa equipe, estudando a possibilidade da utilização de
WPF com Prism.
Nossa solução atual foi criada com a utilização de Windows Forms,
portanto há uma série de fatores que devemos considerar e estudar para
atingir de forma satisfatória os objetivos desta migração.
Dentre as novas características que estão ligadas a estas tecnologias,
está o MVVM Pattern. Este utiliza um conceito um tanto diferente do
que normalmente encontramos por aí e conhecemos.
Apesar de estarmos lendo bastante sobre o padrão, não conseguimos
definir se sua utilização ("puristamente" falando) será realmente
produtiva para nosso propósito, que é a criação de um sistema que
possuirá um número bastante elevado de telas de cadastro (CRUD).
Até onde entendemos, a utilização do padrão causa, por exemplo, um
certo retrabalho na definição dos Models, que devem ser "recriados"
nos ViewModels. Pelo menos é o que temos absorvido das literaturas.
Gostaria de saber se alguém tem algum relato de experiência ou dica
que possa nos guiar a respeito da utilização destas tecnologias.
Abraços.
Diego Stiehl
Fernando
Jan 7, 2012, 11:05:01 AM1/7/12
to .Net Architects
Oi Diego
Eu vou te passar a minha visão como desenvolvedor. Eu sei que muitos
arquitetos consideram o MVVM a melhor coisa que existe, porém vou
passar a experiência que tive como desenvolvedor e talvez falar
algumas coisas que ninguém que evangeliza o MVVM conta, embora o
próprio criador do MVVM já tenha deixado claro, que MVVM não é a
solução para todos os projetos e que em muitos casos ele se torna uma
marreta para matar uma formiga.
Trabalho com WPF e trabalhei um tempo numa empresa que usada MVVM de
uma forma quase fundamentalista/radical em um projeto e acabei saindo
dela em parte por causa disto. A impressão que tive com este projeto
foi que ele sofria dos problemas de "overengineering", e acabou se
tornando muito mais complexo do que era realmente necessário por causa
da forma como os conceitos de MVVM foram aplicados. Por conta de se
ficar tentando deixar a aplicação mais fácil de manter, ela se tornou
um inferno de desenvolver, porque a simples criação de uma
funcionalidade que exbisse um texto em label e respondesse ao
pressionar de um botão demandava dezenas de linhas de código. Até hoje
não sei se esta aplicação foi concluída ou entregue no prazo.
Outra dificuldade que esta empresa tinha era em integrar novos
desenvolvedores na equipe. Como o MVVM é muito diferente do
desenvolvimento .NET/Desktop tradicional, demora muito para pegar
alguém vindo da rua e ensinar a pessoa como codificar desta forma.
Muitos dos recém contratados acabavam saindo da empresa pois era mais
fácil arranjar outro job do que passar o stress de ter que aprender um
novo sistema de desenvolvimento e ainda dar performance.
Eu acho que precisa ter uma visão muito pragmática para dosar a
utilização de MVVM e ver até onde ir. Alguns conceitos são bem úteis,
como o Binding, que facilita bastante a lógica de apresentação dos
dados, outros precisam ser contextualizados, como o uso de IComand
para implementar todas as interações com controles do tipo button.
Algumas vezes ficar escrevendo classes de ICommand, Converters,
Triggers e outros "auxiliares" para fazer algo simples pode não
compensar enquanto outras vezes pode valer a pena para funções
simples, então precisa saber quando fazer as coisas da forma
tradicional e quando que compensa utilizar o MVVM.
Nos projetos em que atuo atualmente a gente usa uma forma bem "light"
de MVVM, usando basicamente o Binding como padrão e usando os outros
recursos somente quando o desenvolvimento compensa o que isto pode nos
trazer de economia de tempo ou facilidade de manutenção. São projetos
geralmente com 100K-200K de linha de código cada, para uma grande
empresa do setor financeiro e geralmente conseguimos trabalhar bem
desta forma. Os projetos são entregues antes do período previsto e não
tivemos problemas de manutenção utilizando este sistema. Embora estes
sistemas não use o Prism da Microsoft, ele usa um outro framework
interno da empresa que é muito semelhante ao Prism e traz os mesmos
benefícios, principalmente em modularidade dos componentes.
Bom, esta é minha experiência.
Fernando Bastos
Eu vou te passar a minha visão como desenvolvedor. Eu sei que muitos
arquitetos consideram o MVVM a melhor coisa que existe, porém vou
passar a experiência que tive como desenvolvedor e talvez falar
algumas coisas que ninguém que evangeliza o MVVM conta, embora o
próprio criador do MVVM já tenha deixado claro, que MVVM não é a
solução para todos os projetos e que em muitos casos ele se torna uma
marreta para matar uma formiga.
Trabalho com WPF e trabalhei um tempo numa empresa que usada MVVM de
uma forma quase fundamentalista/radical em um projeto e acabei saindo
dela em parte por causa disto. A impressão que tive com este projeto
foi que ele sofria dos problemas de "overengineering", e acabou se
tornando muito mais complexo do que era realmente necessário por causa
da forma como os conceitos de MVVM foram aplicados. Por conta de se
ficar tentando deixar a aplicação mais fácil de manter, ela se tornou
um inferno de desenvolver, porque a simples criação de uma
funcionalidade que exbisse um texto em label e respondesse ao
pressionar de um botão demandava dezenas de linhas de código. Até hoje
não sei se esta aplicação foi concluída ou entregue no prazo.
Outra dificuldade que esta empresa tinha era em integrar novos
desenvolvedores na equipe. Como o MVVM é muito diferente do
desenvolvimento .NET/Desktop tradicional, demora muito para pegar
alguém vindo da rua e ensinar a pessoa como codificar desta forma.
Muitos dos recém contratados acabavam saindo da empresa pois era mais
fácil arranjar outro job do que passar o stress de ter que aprender um
novo sistema de desenvolvimento e ainda dar performance.
Eu acho que precisa ter uma visão muito pragmática para dosar a
utilização de MVVM e ver até onde ir. Alguns conceitos são bem úteis,
como o Binding, que facilita bastante a lógica de apresentação dos
dados, outros precisam ser contextualizados, como o uso de IComand
para implementar todas as interações com controles do tipo button.
Algumas vezes ficar escrevendo classes de ICommand, Converters,
Triggers e outros "auxiliares" para fazer algo simples pode não
compensar enquanto outras vezes pode valer a pena para funções
simples, então precisa saber quando fazer as coisas da forma
tradicional e quando que compensa utilizar o MVVM.
Nos projetos em que atuo atualmente a gente usa uma forma bem "light"
de MVVM, usando basicamente o Binding como padrão e usando os outros
recursos somente quando o desenvolvimento compensa o que isto pode nos
trazer de economia de tempo ou facilidade de manutenção. São projetos
geralmente com 100K-200K de linha de código cada, para uma grande
empresa do setor financeiro e geralmente conseguimos trabalhar bem
desta forma. Os projetos são entregues antes do período previsto e não
tivemos problemas de manutenção utilizando este sistema. Embora estes
sistemas não use o Prism da Microsoft, ele usa um outro framework
interno da empresa que é muito semelhante ao Prism e traz os mesmos
benefícios, principalmente em modularidade dos componentes.
Bom, esta é minha experiência.
Fernando Bastos
Fernando
Jan 7, 2012, 11:23:48 AM1/7/12
to .Net Architects
Oi Diego
Ah, ia já esquecendo. Se for usar o MVVM de forma mais intensa, eu
recomendo que você compre algumas licenças do Expression Blend
Ultimate para os seus desenvolvedores, embora teoricamente tudo possa
ser feito também no Visual Studio, usar MVVM sem trabalhar com o
Expression Blend é meio como escrever aplicações web com o Notepad.
Muitas das ferramentas e automatizações que ele fornece não estão
disponíveis no Visual Studio 2010.
Fernando
Ah, ia já esquecendo. Se for usar o MVVM de forma mais intensa, eu
recomendo que você compre algumas licenças do Expression Blend
Ultimate para os seus desenvolvedores, embora teoricamente tudo possa
ser feito também no Visual Studio, usar MVVM sem trabalhar com o
Expression Blend é meio como escrever aplicações web com o Notepad.
Muitas das ferramentas e automatizações que ele fornece não estão
disponíveis no Visual Studio 2010.
Fernando
Ricardson Albuquerque
Jan 7, 2012, 5:30:57 PM1/7/12
to dotnetar...@googlegroups.com
se o vs nao suporta e o blend sim nao caberia ao designer ?
--
Ricardson Albuquerque
--
Você recebeu esta mensagem porque faz parte do grupo .Net Architects hospedado no Google Groups.
Para postar envie uma mensagem para dotnetar...@googlegroups.com
Para sair do grupo envie uma mensagem para dotnetarchitec...@googlegroups.com
Para mais opções visite o grupo em http://groups.google.com/group/dotnetarchitects?hl=pt-br
Ricardson Albuquerque
Fernando
Jan 8, 2012, 5:03:50 PM1/8/12
to .Net Architects
Oi Ricardson
Pelo menos nos locais que trabalhei o desenvolvedor também era
responsável pela implementação das telas (o que o designer quando
existia, enviava eram PPT ou arquivos PSD com o visual da tela, nunca
conheci um que soubesse XAML por estes lados), mas a implementação do
XAML era responsabilidade do desenvolvedor. Agora se você tiver um
local onde tenha uma pessoa que te entregue o XAML já pronto,
realmente não precisa do Blend.
Fernando
Pelo menos nos locais que trabalhei o desenvolvedor também era
responsável pela implementação das telas (o que o designer quando
existia, enviava eram PPT ou arquivos PSD com o visual da tela, nunca
conheci um que soubesse XAML por estes lados), mas a implementação do
XAML era responsabilidade do desenvolvedor. Agora se você tiver um
local onde tenha uma pessoa que te entregue o XAML já pronto,
realmente não precisa do Blend.
Fernando
Secco
Jan 9, 2012, 7:55:13 AM1/9/12
to dotnetar...@googlegroups.com
Olá Fernando.
Valeu pela ajuda. Realmente deu uma clareada na minha mente a respeito do assunto.
Acho que possuo uma visão próxima a tua com relação ao MVVM: parece ser uma padrão incrível, mas se for incorretamente (ou exageradamente) aplicado, pode realmente ser como uma bazuca para matar uma formiga (e quem sabe a formiga até fica viva ainda... Hehe).
O jeito, por enquanto, é dar uma aprofundada nos conhecimentos.
Estou dando uma estudada em alguns frameworks que encontrei, que prometem facilitar o desenvolvimento MVVM. Conhece o Caliburn? O que me diz dele?
Estou dando uma estudada em alguns frameworks que encontrei, que prometem facilitar o desenvolvimento MVVM. Conhece o Caliburn? O que me diz dele?
No mais, muito obrigado pela atenção.
Diego Stiehl.
Cassiano Kuss
Jan 9, 2012, 8:01:01 AM1/9/12
to dotnetar...@googlegroups.com
Um bem legal é o
http://simplemvvmtoolkit.codeplex.com/
Ricardson Albuquerque
Jan 9, 2012, 8:15:28 AM1/9/12
to dotnetar...@googlegroups.com
Fernando,
--
Ricardson Albuquerque
Entendo que geralmente o desenvolvedor irá trabalhar tanto no vs como no blend.
Mas acredito que o melhor cenário possível, é o designer saber usar o blend, e dividirem os trabalhos justamente até onde o blend deixar o designer ir.
A própria microsoft demonstra vários cenários, seja o desenvolvedor fazendo tudo, o designer first, o desenv first etc...
Só quis chamar atenção, pois a depender do tamanho do projeto, separar estas atividades seria o melhor caminho, até pq se não houvesse esta distinção de papeis, e a possibilidade de colaboração designer no blend, e desenv no vs trabalhando no mesmo xaml, pois a proposta de criação do xaml é justamente esta tal colaboração.
2012/1/9 Secco <secc...@gmail.com>
Ricardson Albuquerque
Vinicius de Melo Rocha
Jan 9, 2012, 5:29:43 AM1/9/12
to dotnetar...@googlegroups.com
Oi pessoal,
--
Vinicius de Melo Rocha
Eu trabalho no CESAR em Recife. Tive a oportunidade de trabalhar em dois
projetos usando WPF e em ambos os projetos tivemos a oportunidade de ter
dois designers que usavam o Blend e o Ilustrator para criar o styles pra gente.
Não usávamos MVVM e os designers não trabalhavam direto no nosso código,
eles apenas geravam os styles para gente incorporar na aplicação. (arquivos de resource)
Abraço,
Fernando
--
Você recebeu esta mensagem porque faz parte do grupo .Net Architects hospedado no Google Groups.
Para postar envie uma mensagem para dotnetar...@googlegroups.com
Para sair do grupo envie uma mensagem para dotnetarchitec...@googlegroups.com
Para mais opções visite o grupo em http://groups.google.com/group/dotnetarchitects?hl=pt-br
Vinicius de Melo Rocha
Rafael Hrasko
Jan 9, 2012, 10:45:26 AM1/9/12
to dotnetar...@googlegroups.com
"Muitos dos recém contratados acabavam saindo da empresa pois era mais
fácil arranjar outro job do que passar o stress de ter que aprender um
novo sistema de desenvolvimento e ainda dar performance. "
fácil arranjar outro job do que passar o stress de ter que aprender um
novo sistema de desenvolvimento e ainda dar performance. "
I don't wanna live in this planet anymore
Minha opinião? MVVM não é nem bazuca para matar formiga, pois isso implica que é uma solução 'boa demais', que se o problema fosse maior seri ideal. Para mim, é uma solução que pode ser aplicada em alguns sistemas (cá entre nós, a maioria). Em alguns na verdade o MVVM atrapalha, pelos mesmos problemas da 'otimização prematura'
Citando Jonathan Blow:
"Bom desenvolvedor é (...) alguém que tem um vasto conhecimento de idéias e técnicas avançadas, mas só as utiliza quando ajuda genuinamente o desenvolvimento"
Sds
Sds
Victor Arias
Jan 9, 2012, 1:18:17 PM1/9/12
to dotnetar...@googlegroups.com
Na minha opinião utilizar MVVM esta longe de ser "overengineering" - na verdade acredito ser justamente o contrario: faltou engenharia para melhorar a aplicação do padrão.
Quem conhece o Caliburn e cia sabe muito bem que a história fica beeeem diferente se utilizado um framework para facilitar.
E viva o webforms! *put a trollface here*
Reply all
Reply to author
Forward
0 new messages