segunda-feira, 23 de fevereiro de 2009

Workshop sobre padrões de projeto.

Realizei na empresa em que trabalho um workshop sobre padrões de projetos. Eu já imaginava que seria complicado falar sobre esse assunto, e realmente foi. Nos trinta minutos finais do workshop, quando já estava batendo papo como se estivesse em uma roda de amigos, acabei conseguindo o que tanto queria, criar polêmica. Apresentei no workshop apenas um formulário de login utilizando MVC juntamente com outros padrões, procurando deixar claro que muita coisa estava ali apenas para analisarmos os padrões, também aproveitei a brecha para apresentar o DDD.

Após realizar a apresentação formal do projeto, perguntei a todos o que eles encontraram de errado no projeto e críticas que tinham para fazer do mesmo, e somente nos trinta minutos finais eles resolveram fazer as suas considerações, são elas:


“Você esta utilizando MVC para uma tela de login, mas foi construído somente para fins didáticos, você não faria isso em um projeto real, certo?”
R.: Os padrões de projeto são conjuntos de “problemas + solução” se não existe o problema não tem porque aplicar a solução. Por isso é importante conhecer e entender os princípios por trás dos padrões, para saber exatamente onde aplicá-los. O application guide da microsoft até preve a construção de interfaces sem a utilização de MVC e da umas dicas de quando utilizá-lo.
http://msdn.microsoft.com/en-us/library/ms978348.asp


“O objetivo do MVC é reaproveitamento de código certo? Por tanto, qual deve ser o prcedimento quando um controller precisa se comportar de forma diferente para cada view? Ex.: Imagine que eu tenha uma tela que me traga 1000 registros, agora imagine a mesma aplicação rodando em um celular, o celular não tem capacidade gráfica para suportar os 1000 registros, como ficaria a minha controller nesse caso?”
R.: O MVC contribui com o reaproveitamento de código sim, mas ele tem um objetivo claro “separar lógica de negócio da lógica de apresentação”. No exemplo informado imagine que na mesma tela de pesquisa o usuário tenha um campo onde ele pode informar quantos registros queremos exibir por página. O que mudou entre a view e a controller? Perceba que a view pode informar a controller quantos registros por página ela consegue suportar, mesmo que não seja um campo visível para o usuário. Agora isso não quer dizer que vamos conseguir construir um único controller para todas as telas em todas as plataformas possíveis, construir outras controller é totalmente admissível e em alguns casos inevitável.


“Quando você manda para controller alguns dados e no meio do fluxo é necessário abrir uma outra tela, é a controller que deve fazer isso, certo?”
R.: Sim e não, a controller com certeza deve saber que é necessário abrir uma outra tela, mas se você deixar na controller o nome da página *.aspx, o nome do formulário ou nome do *.swf a controller fica extremamente ligada a arquivos de interface o que não é legal (isso acontece hoje no padrão Page Controller utilizado nas páginas *.aspx). Nesse caso sugiro duas soluções:

  • A controller notifica a view que ela deve abrir uma outra página e ela se encarrega de realizar essa ação (não é muito bonito mas funciona);
  • Existe um padrão responsável em controlar as chamadas para outras interfaces chamado Front Controller que também pode ser aplicado.

Com certeza esse assunto pode trazer mais dúvidas e discussões interessantes, não deixem de postar seus comentários.