Escolha de arquiteturas para interface gráfica

[Giovanni Bassi]

Pessoal,

Estou curioso, e gostaria de jogar uma discussão aqui no grupo.
Falamos muito de testes, DDD, TDD, linguagens dinâmicas, processos, e até missão crítica saiu recentemente. O que vejo sendo pouco discutido é sobre a arquitetura da interface gráfica.
Gostaria de saber dos colegas o que vocês tem usado, se avaliam as opções, se tem um modelo conciente de escolha, enfim, como trabalham.

Pergunto isso porque é mais frequente que eu atenda clientes que tem grandes dúvidas no código de negócio, e resolvemos isso com técnicas diversas. Mas quando chegamos na IG muitos dizem que se viram, e depois de uns meses me ligam com problemas, porque o código na IG está impossível de manter. Nos projetos ASP.Net, temos o famoso padrão "Page Controller", que parece ser entendido como "faça o que você bem entender". Isso acontece também com projetos Winforms, e até o novo WPF.
Poucos realmente entendem a separação do código da visão do seu comportamento, e praticamente ninguém testa código de IG. Quase ninguém entende ou sabe o que é MVVM, MVC, MVP, PM, etc...

Se puderem dar uma visão sobre seu processo de decisão, se é que existe (ou de empresas em que trabalharam ou viram funcionando), seria interessante para pesarmos se isso é algo generalizado no mercado. Além disso, gostaria de uma perspectiva sobre os modelos que vocês tem mais usado, e os casos de sucesso e fracasso.

(Daniel, sugestão quente para um podcast.)

[]'s

Giovanni Bassi
Microsoft MVP, MCSD, MCPD, CSM
Arquiteto de software
http://www.giovannibassi.com

[Alessandro de Souza]

Falando um pouco sobre o teste unitário para interface gráfica.
Como seria este tipo de teste em ASP.NET MVC?. Pelo pouco que conheço no MVC o teste é mais focado nos controllers....

Att,
Alessandro

2009/11/5 Giovanni Bassi <gig...@giggio.net>

[alessandr...@gmail.com]

Falando um pouco sobre o teste unitário para interface gráfica.
Como seria este tipo de teste em ASP.NET MVC?. Pelo pouco que conheço
no MVC o teste é mais focado nos controllers....

Att,
Alessandro

[Giovanni Bassi]

Pessoal, ninguém tem nada pra contar? Fico preocupado, estamos deixando de lado algo muito importante...

[]'s

Giovanni Bassi
Microsoft MVP, MCSD, MCPD, CSM
Arquiteto de software
http://www.giovannibassi.com

2009/11/5 Giovanni Bassi <gig...@giggio.net>

[Vinicius Quaiato]

Não tenho experiências práticas com isso.

Porém hoje estava conversando com o Diogo Menezes, e pensei em algo:
A interface gráfica não é dependente das classes de domínio? Testando as classes de domínio a IG não está "teoricamente" testada?

Como funcionária na prática os testes da IG?

Att,
Vinicius Quaiato
www.viniciusquaiato.com

Google Talk: vinicius.quaiato

Twitter

2009/11/9 Giovanni Bassi <gig...@giggio.net>

[André Dias]

Estamos nada, ouvi dizer que no próximo sábado você vai apresentar pra gente um deep dive em arquitetura de interface gráfica, não é mesmo?? J

 

[]s

[Juliano Oliveira]

Bom, 

Em Flex, o recomendado seria MVVM, se não me engano, que é uma aqrquitetura onde a view tem suas próprias classes, como VO´s (correto?)

Nesse cenário (Flex + .Net com DDD) dá um trabalhão. Em geral, o legal é "replicar" suas classes de domínio no Flex, com ActionScript. Desse jeito fica elegante demais... mas um problema que se tem é o controle de alterações. Por exemplo, se vc alterar o dominio, deve alterar as classes do Flex e isso é muito ruim. Torna um tormento o desenvolvimento. A grande vantagem é a serialização/deserialização dos objetos entre a view e o servidor da aplicação. Usando um framework de remoting, como o FluorineFx ou o WebORB, essa "impedância" entre plataformas é transparente e bem leve.

O MVVM com Flex+.Net é legal mas temos um grande problema com "a mudança", que é um dos pontos fortes do DDD. Ou seja, se você usa DDD como arquitetura do seu negócio e MVVM na sua view (acho que mesmo em Silverlight isso acontece) você perde uma vantagem do DDD.

[]´s

Juliano Oliveira
Analista Desenvolvedor
.Net, C#, Actionscript, Flex, NHibernate
twitter: @juloliveira - skype: juloliveira
http://programandoem.net
http://www.plug7.com.br

2009/11/9 Giovanni Bassi <gig...@giggio.net>

[Rodolfo Nat]

Não sei se tem muito a ver com o assunto, mas na empresa onde trabalho, fazemos testes funcionais utilizando o Selenium.
Dai gravamos os scripts e rodamos na medida do necessário.

Att,
   Rodolfo Natanael
   MCP, MCTS - Web Applications 2.0

2009/11/9 Juliano Oliveira <jul.ol...@gmail.com>

[Juan Pedro A. Lopes]

Na empresa onde eu trabalho, também usamos o Selenium. A melhor configuração foi gerar os testes no NUnit e rodar o Selenium RC no servidor de integração. Mas isso só foi feito em um projeto =/

Até pq criar os testes no selenium é mais chato que criar um teste unitário, por exemplo.

2009/11/9 Rodolfo Nat <rodol...@gmail.com>

--
Kind regards,
Juan Lopes

juanp...@gmail.com
con...@juanlopes.net
http://juanlopes.net
http://twitter.com/juanplopes

[Alexandre Valente]

Oi Giovanni,

No nosso caso, seguimos a linha de minimizar o código de interface ao máximo justamente pela dificuldade de testar (no sentido mais amplo da coisa! rsrsrs). 

Como falei no meu blog, eu parti, já há bastante tempo, pra uma linha declarativa, com uso massivo de XSLT. Embora seja dificil de encontrar profissionais capacitados, e com uma curva de treinamento sinistra, eu vejo um ganho claro na diminuição da complexidade de controllers e da comportamento. A gente separa a parte de "layout" com um XSLT que recebe um XML de "comportamento" e outro de "dados", e aí interface HTML é gerada com uma transformação simples. Sem loops, ifs ou qqer coisa muito complexa de debugar. E os códigos de comportamento ficam super "clena". Finalmente, gerar o XML de dados tbm é tranquilo, o que gera controllers bem enxutos.

O único problema é a parte dinâmica da página, que a gente faz em jquery. Isto é muito complicado de testar e garantir qualidade, escrever testes em coisas como o Selenium é possível, mas extremamente demorado. A minha estratégia pra isto tem sido tentar encapsular cada vez mais o código jquery no XML de "comportamento", o que minimiza a quantidade de código jquery customizado, o que por consequencia diminui a chance de erros.

Mas mesmo assim, juntando o tempo de criação/adaptação do layout com o tempo de criação/debug de jquery, a parte de interface consome, na nossa experiencia, mais de 80% do tempo da construção de qualquer aplicação. Acho isto horrível, e tenho trabalhado com afinco pra tentar diminuir isto. Mas como vc falou é uma área que é muito aberta, onde se ve de tudo e com os mais variados resultados. E na parte de interface eu não tenho muita esperança de melhoria a curto prazo não, embora tenhamos conseguido uma série de automatizaçãoes interessantes (mas vai muito bem até o negócio necessitar de uma interface "diferente", aí toca a expandir mais os layouts e o xslt empregados, o que consome muito tempo).

abs

Alexandre Valente

MCSE+I, MCSD, MDCBA, ITIL, CSM

agvalente.wordpress.com 

2009/11/5 Giovanni Bassi <gig...@giggio.net>

[Juan Pedro A. Lopes]

Alexandre, eu usei seu esquema de transformação XSLT e confesso que fiquei um pouco perdido. Gastava-se mais tempo debuggando o XSLT do que gerando interfaces por si só.

---

Em contra-partida, fiz o último projeto em ASP.NET MVC e sinceramente foi o projeto mais perfeito que eu já participei, em termos de interface. Contratamos um designer freelancer, que fez um design simplesmente sinistro. Ele foi facilmente aplicado. A partir dai, não tive mais problemas.

Considero que o ASP.NET MVC seja fechado e perfeito no que ele se dispõe a fazer.

2009/11/9 Alexandre Valente <alexandre...@gmail.com>

[Rodolfo Nat]

será q alguem tem algum exemplo de esquema de transformação em XSLT? Fiquei curioso, nunca vi.

Att,
   Rodolfo Natanael
   MCP, MCTS - Web Applications 2.0

2009/11/9 Juan Pedro A. Lopes <zero...@gmail.com>

[Alexandre Valente]

Oi Juan,

Vc pegou em uma fase onde isto estava sendo concebido, realmente era muito mais dificil! :-)

Hoje está bem mais tranquilo, nos novos projetos tem muito pouca alteração nos XSLTs de controles. Layouts ainda tem que ser mexidos bastante, mas somente no início dos projetos.

Mas é claro que não é fácil, como eu falei, achar profissionais que dominem bem XSLT (e que gostem e/ou queiram aprender) não é tarefa simples. Porém eu ainda acho que se paga. Este fim de semana tive uma ótima experiência, consegui colocar no ar um protótipo para sistema, ainda que bem simples, em menos de 4h.... Ou seja, a produtividade (pra quem domina, obviamente) é bastante elevada.

Mas, de todas as minhas escolhas, esta é a mais "dificil" de ser defendida. É uma questão de gosto e produtividade direta da equipe somente. E tem algumas vantagens, de controllers pequenos, pouco código, o que facilita toda a parte de teste e controel de qualidade.

Ah sim, e hoje nas entrevistas a gente deixa extremamente claro que será necessário trabalhar (muito) com XSLT assim, ninguem mais entra e tem surpresas!!  :-) :-)

abs

Alexandre Valente

MCSE+I, MCSD, MDCBA, ITIL, CSM

agvalente.wordpress.com 

2009/11/9 Juan Pedro A. Lopes <zero...@gmail.com>

Alexandre, eu usei seu esquema de transformação XSLT e confesso que fiquei um pouco perdido. Gastava-se mais tempo debuggando o XSLT do que gerando interfaces por si só.

[Alexandre Valente]

Oi Rodolfo,

Olha este link, eu explico de maneira básica a idéia geral. 

http://agvalente.wordpress.com/2009/09/05/produtividade-camada-de-interface-parte-1/

Se quiser exemplos maiores, me manda um email particular pra eu não ficar poluindo a lista com muito texto XML :-)

abs

Alexandre Valente

MCSE+I, MCSD, MDCBA, ITIL, CSM

agvalente.wordpress.com 

2009/11/9 Rodolfo Nat <rodol...@gmail.com>

[Alexandre Valente]

Ah sim, cabe notar que eu não sou o único a seguir esta linha. Existem várias outras engines de transformação XSLT pros frameworks MVC, tanto para o Monorail quanto para o MS MVC (este até suporta alguma coisa de forma nativa na forma de viewresult). Um search no google e vc acha outros exemplos,

Eu parti pra uma ViewEngine própria porque queria integrar isto com o código js gerado e também facilitar a geração de dados dos controllers.... Fazer isto com o que eu vi pronto teria sido mais dificil. 

abs

Alexandre Valente

MCSE+I, MCSD, MDCBA, ITIL, CSM

agvalente.wordpress.com 

2009/11/9 Alexandre Valente <alexandre...@gmail.com>

[Juan Pedro A. Lopes]

Alexandre, realmente eu não domino XSLT.

O problema também é que a única coisa que me faz gostar mais de C# que de Ruby é o fato de ele ser estaticamente tipado. De certa forma, introduzir um XSLT, que é um elemento não compilável, no processo de desenvolvimento é algo que me deixa um pouco incomodado.

De qualquer forma, é uma questão de gosto. :)


2009/11/9 Alexandre Valente <alexandre...@gmail.com>

[Giovanni Bassi]

Juliano,

Pelo que sei, o MVVM é aplicável só para WPF e Silverlight, já que, na prática, ele é dependente de algumas soluções técnicas destas tecnologias. O MVVM nada mais é que um Presentation Model com algumas coisas um pouco diferentes.
E não vejo nenhum problema em usar MVVM com DDD.

[]'s

Giovanni Bassi
Microsoft MVP, MCSD, MCPD, CSM
Arquiteto de software
http://www.giovannibassi.com

2009/11/9 Juliano Oliveira <jul.ol...@gmail.com>

[Giovanni Bassi]

Vinicius,

Se você testou as classes de domínio, só isso está testado! A IG, que faz toda a coordenação de telas, e a camada de aplicação, que coordena todo o fluxo da app, também podem (e devem) ser testadas.
Para testar detalhes da visão, somente com alguma suite de testes focada nisso. Alguém citou Celenium, e agora no Visual Studio 2010 também teremos ferramentas que suportarão esse tipo de teste. Mas esses são os testes mais difíceis pra fazer. Antes deles, você deve buscar os testes que especificam e validam toda a coordenação das visões. Se for com MVVM, testa os viewmodels, se for com MVP ou MVC, testa o controller, se for com PM, testa o PM, e por aí vai.

[]'s

Giovanni Bassi
Microsoft MVP, MCSD, MCPD, CSM
Arquiteto de software
http://www.giovannibassi.com

2009/11/9 Vinicius Quaiato <vinicius...@gmail.com>

[Giovanni Bassi]

Putz, no próximo sábado só se eu arranjar mais umas 30 horas livres até lá, e acho que vai ser impossível! :)
Mas não descarto a possibilidade em outra reunião. Ou outra pessoa assume e ganha um Resharper (já que eu já tenho um).

[]'s

Giovanni Bassi
Microsoft MVP, MCSD, MCPD, CSM
Arquiteto de software
http://www.giovannibassi.com

2009/11/9 André Dias <br.a...@hotmail.com>

[Vinicius Quaiato]

Giovanni,

Estes testes avaliariam se as views apontam para controles certos? Passando os parâmetros certos?

Att,
Vinicius Quaiato
www.viniciusquaiato.com

vinicius.quaiato

Twitter

2009/11/10 Giovanni Bassi <gig...@gmail.com>

[Juliano Oliveira]

Giovanni,

Não entendi? Por que você acha que MVVM não é aplicavel ao Adobe Flex?

[]´s

Juliano Oliveira
Analista Desenvolvedor
.Net, C#, Actionscript, Flex, NHibernate
twitter: @juloliveira - skype: juloliveira
http://programandoem.net
http://www.plug7.com.br

2009/11/9 Giovanni Bassi <gig...@gmail.com>

[Juliano Oliveira]

mm... estive dando uma lida sobre. Bem como eu disse, "se não me engano".. hehe...

Pensei que o nome da arquitetura fosse a mesma no Adobe Flex. 

Por acaso sabe o nome desse desenho de arquitetura?

[]´s

Juliano Oliveira
Analista Desenvolvedor
.Net, C#, Actionscript, Flex, NHibernate
twitter: @juloliveira - skype: juloliveira
http://programandoem.net
http://www.plug7.com.br

2009/11/9 Juliano Oliveira <jul.ol...@gmail.com>

[Giovanni Bassi]

O MVVM é um Presentation Model com algumas coisas a mais no que diz respeito ao databinding e no envio das mensagens.

[]'s

Giovanni Bassi
Microsoft MVP, MCSD, MCPD, CSM
Arquiteto de software
http://www.giovannibassi.com

2009/11/10 Juliano Oliveira <jul.ol...@gmail.com>

[Giovanni Bassi]

Oi Vinicius,

Como assim, se as views apontam para os controles certos? Os controles das views são de responsabilidade dela... O controller não tem que saber sobre os controles das views.
Os testes validam, por exemplo, que ao chamar a ação "logar" do controlador com os valores corretos, se um valor no modelo é atualizado, ou se uma nova ação é transmitida à view (depende da arquitetura utilizada).

[]'s

Giovanni Bassi
Microsoft MVP, MCSD, MCPD, CSM
Arquiteto de software
http://www.giovannibassi.com

2009/11/10 Vinicius Quaiato <vinicius...@gmail.com>

[Vinicius Quaiato]

Giovanni, é que pelo que se tinha dito nos emails anteriores pra mim estava bem claro que este teste dos controllers deveria ser feito, e é totalmente possível de se realizar testes de unidade com eles.

No entanto achei que você estava querendo de fato testar, se alguma forma ninja, as views em si.

Talvez eu tenha entendido totalmente errado. Pois pra mim pareceu bem lógico que os controller são testáveis =D

[Bruno DAléssio]

Eu ia abrir uma thread nova, mais me lembrei dessa e se encaixa perfeitamente.

Sendo assim vou responder a pergunta principal e levantar outra.

 

Venho trabalhando com Windows Forms a algum tempo, utilizo o padrão MVC na UI com isso converso com o back-end facil e elegantemente.

 

Agora a duvida:

Alguem trabalha ou ja trabalhou com WF, e implementou algum conceito de padrões, MVC, MVP ou qualquer outro?

 

A parte de back-end você acha facilmente "cases" sobre diferentes arquiteturas mais na parte da UI creio que as pessoas tendem a simplificar e não dão muito valor. Até mesmo para WEBFORMS isso vale.

 

Basicamente estou reforçando a pergunta do Bassi, mais puxando pro meu lado.

 

Expêriencias com plataforma WEB tambem são válidas, mais queria mesmo saber na plataforma WF.

 

 

Abraço galera,

--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---

--
"Um passo a frente e você não esta mais no mesmo lugar!"

Chico Sciense

[Thiago Alves]

Opa,

No ASP.NET MVC existe o conceito de "presentation model" que não necessariamente está acoplado ao business model.

Vou dar um exemplo prático e queria que vocês me dissessem se faz algum sentido (já aviso que o código não é dos mais bem escritos). Vamos lá:

Imagine uma tela que exiba data de criação de algum objeto. Exemplo: "12/Jan/2010"

Mas se o dia foi ontem deve exibir "Ontem" em vez de "27/Jan/2010"

E se o dia for hoje, deve exibir a hora: "Hoje às 12h33"

O sistema deve funcionar em português e data no formato brasileiro, se o usuário está acessando o sistema do Brasil, e deve funcionar em inglês e data no formato americano, se acessar de outro país.

Então no domain model teríamos

class User {

    public DateTime CreationDate {get;set;}

}

No controller, teríamos:

class UserController {

      public ActionResult ShowUser(Int32 id) {

            User user = userService.get(id);

            UserViewModel userViewModel = new UserViewModel(user);

            userViewModel.Culture = Thread.CurrentThread.CurrentUICulture.ToString();

            return View(userViewModel);

      }

}

No view (presentation) model:

class UserViewModel {

    public User User { get;set; }

    public UserViewModel (User user) {

        this.User = user;

    }

    public String Culture { get; set; }

    public String GetFormattedDate() {

          if (this.User.CreationDate.Date == DateTime.Today) {

              if (this.Culture == "pt-br") {

                   return "Hoje às " + this.User.CreationDate.ToShortTimeString();

              } else {

                    return "Yesterday at " + this.User.CreationDate.ToShortTimeString();
              }

          }

          else if (this.User.CreationDate.Date == DateTime.Today.AddDays(-1)) {

                 if (this.Culture == "pt-br") {

                       return "Ontem"; // TODO: ler de resource file

                 } else {

                       return "Yesterday";

                 }

          } else {

                 return this.User.CreationDate.ToShortDateString();

          }

     }

}

E aí a view exibiria o Model.GetFormattedDate() (ou seja, toda a inteligência de interface estaria no ViewModel e a view seria totalmente burra, apenas se preocupando em exibir dados do objeto ViewModel.

E aí ficaria simples escrever um script de teste para a classe ViewModel. E o fato de a classe de domínio estar testada não necessariamente garante que a data vai ser exibida corretamente na tela.

Faz algum sentido isso? Nunca escrevi testes automatizados de interface... todos os testes de interface aqui são feitos por pessoas...

Nunca me deparei com uma interface que merecesse um script de teste só para ela. Alguém já teve essa necessidade?

Abraços,

Thiago Alves

2009/11/9 Vinicius Quaiato <vinicius...@gmail.com>