 |
Por Dennes Torres  dennes@bufaloinfo.com.brDennes Torres possui as certificações MCAD, MCSD,MCSE, MCDBA e MCT. Atualmente atua como diretor da Búfalo Informática, líder do grupo de usuários DevASPNet, co-lider dos grupos devSQL e getWindows no Rio de Janeiro, podendo sempre ser encontrado na lista de discussão do grupo DevASPNet (devaspnet-subscribe@yahoogrupos.com.br) bem como nas reuniões do grupo. Possui também um blog em http://cidadaocarioca.blogspot.com |
|
|
|
| Analisando uma aplicação ASP.NET MVC | |
|
|
|
O objetivo deste artigo é analisar uma aplicação criada utilizando-se do framework ASP.NET MVC. O exemplo analisado será o de criação de uma aplicação de cesta de compras com MVC. Este artigo será todo referenciado ao artigo de criação da aplicação.
Flexibilidade ?
No item 1 vemos a forma como o projeto de MVC é razoavelmente engessado em seu formato, a separação de views, models e controllers é bem rígida.
Se você já estudou consideravelmente o arquitetura do ASP.NET MVC então já sabe que ele é extremamente versatil e permite a manipulação das views, controllers e models de uma forma que vai muito além dos templates padrões.
Porém a manipulação além dos templates padrões significa manipular o próprio modelo ASP.NET MVC, faze-lo se transformar em alguma outra coisa e eventualmente em algo que nem ao menos seja MVC.
Por isso, em uma visão simples o ASP.NET MVC é, sim, bem rígido, mas construido sobre um padrão mais amplo que permite a geração de muitos outros resultados.
Separação de Camadas
O model, dsNorth, poderia perfeitamente ser inserido em um assembly a parte, garantindo uma melhor separação das camadas. De fato, recomendo que aqueles que se aventurarem pelo MVC realmente façam isso.
Porém o controller está bem mais amarrado com a view, dificultando ou até impedindo que o controller seja inserido em um assembly a parte.
Por que separar os assemblies ?
Para garantir a manutenção de nossa aplicação a melhor forma é garantir que as regras de negócio sejam centralizadas em pontos únicos. Assim sendo para cada regra de negócio que precisarmos alterar teremos um único local para realizar a alteração, simplificando todo o trabalho e gerando agilidade.
Como em um sistema frequentemente utilizamos multiplas interfaces (web, windows, móveis, etc.) torna-se fundamental que os componentes de regra de negócio possam ser acessados a partir destas múltiplas interfaces, dai a separação de assemblies.
Amarração do controller com a interface
No item 5, método listar, observamos como o controller é amarrado com a interface. Ao utilizar a instrução RenderView isso prende o controller com a aplicação web, impedindo que o controller seja utilizado em outros tipos bem diversos de aplicações, tal como aplicações desktop eventualmente conectadas.
Conforme descrevemos anteriormente o conceito de componente de processo, o controller do padrão MVC deveria realizar esta tarefa, mas no ASP.NET MVC a amarração com a interface é extrema.
MVC ou MVP ?
No item 6 vemos a ligação entre a view e o model, destacando o formato do modelo MVC. Conforme mostramos anteriormente, além do MVC existe também o Model View Presenter, que realiza um isolamento maior entre as camadas, mas de maior complexidade pelo maior uso de interfaces pare reduzir o vínculo.
Relação entre Programação e Design
Com o surgimento do ASP.NET avançamos muitos e muitos anos na separação do trabalho do designer gráfico e do programador. Com o uso de master pages, themes e user controls o programador se tornou muito mais independente do designer gráfico.
Conforme vocês podem observar entre os itens 9 e 30, o ASP.NET MVC regride esses avanços, envolvendo novamente o desenvolvedor com o designer gráfico. Por mais que o uso de CSS permita isolar as características de design gráfico, isso não chega nem próximo do isolamento em que estávamos com o ASP.NET.
Mas não para por ai, entre os itens 31 e 35, além de outros mais adiante, vemos a clássica mistura de codificação e design em um único arquivo, mistura essa da qual já estávamos livres desde o ASP clássico, substituido em 2002 pelo ASP.NET.
Estamos então regredindo 6 anos no desenvolvimento web ?
Vale mencionar, para apimentar mais o debate, que apesar dos avanços que estes 6 anos trouxeram para o desenvolvedor, o web designer não ganhou muito durante este período. O web designer, que se preocupa com a qualidade visual e tem todo seu trabalho visual a fazer, passou a estar envolvido com o conceitos estranhos como webControls, master pages, themes e assim por diante, sendo que as ferramentas de design gráfico sempre demoram para acompanhar a evolução do desenvolvimento de software.
Um outro exemplo são os Html Helpers, demonstrados em vários itens a partir do 46. Eu utilizei muito essa técnica nos anos anteriores a 2002 para criar amplos frameworks de desenvolvimento que simplificassem o trabalho do desenvolvedor.
O uso de tags processadas no servidor para gerar o HTML (os webControls) foi um grande avanço sobre os helpers, sendo que os control adapters fazem o trabalho adicional para possíveis personalizações deste HTML. Trazer os helpers de volta, mais uma vez, é estarmos regredindo anos no desenvolvimento para a web.
Regras de negócio no Model
Os itens 40, 41 e 42 demonstram a criação de regras de negócio no nível do model. Uma visão superficial deste assunto poderia levar a supor que perderíamos em manutenção. Mas já demonstramos antes o uso de partial classes para implementação de regras de negócio nos tableAdapters, o que pode ser visto também neste webcast de desenvolvimento em camadas na web com .NET.
Portanto o model possui na verdade duas camadas, não uma : A camada de negócio e a camada de acesso a dados. Isso condiz com o exemplo que citamos em que o MVC não precisa ser apenas feito em 3 camadas.
Controller como Componente de Processo
No item 43 vemos claramente o controller atuando como componente de processo, realizando uma tarefa de processo complexa envolvendo dois diferentes componentes de negócio que possuem independência entre si. O controller coordena as atividades dos dois componentes de negócio, podendo até mesmo criar uma transação envolvendo os componentes de negócio.
Por causa desta característica crítica, o controller precisaria estar isolado do restante do sistema, podendo ser reutilizado por qualquer camada de interface que precisasse realizar este processo.
Infelizmente isso não ocorre, havendo um forte vínculo do controller com o ASP.NET MVC e prejudicando a manutenção de sistemas futuros.
Observem que o modelo gerado é muito semelhante ao modelo com componente de processo que apresentei anteriormente, porém com perdas devido ao não isolamento do controller.
Conclusão
O ASP.NET MVC, em busca de seguir rigidamente um padrão, nos faz retroceder 6 anos no desenvolvimento web. O benefício de maior testabilidade não compensa a perda na capacidade de manutenção e a perda de produtividade que temos.
O padrão não deveria ser perseguido de forma tão rígida, mas sim de forma a se adaptar a tecnologia na qual é implementado, resultando em capacidade de manutenção e produtividade. Ao tentar adaptar a tecnologia ao padrão, perdemos exatamente estas 2 importantes características do desenvolvimento com ASP.NET
É claro que este assunto gera muitos debates. Todos são muito bem vindos no grupo devASPNet para debater este tema, basta enviarem um e-mail para devaspnet-subscribe@yahoogrupos.com.br