Atualmente quando falamos de arquitetura, vemos esforços em manter a lógica do Domínio isolada, no caso de quem trabalha com Domain Drive Design, e ter camadas com clara separação de responsabilidades, manter um baixo acoplamento na hora de fazer as camadas se comunicarem, mais, também não podemos esquecer da UI. A UI( user interface ), ou, interface com o usuário, geralmente é o front-end com quem nosso usuário final interage e realiza suas principais ações, como inserção de dados, pesquisas, geração de relatórios e etc; Na hora de definir a arquitetura de um sistema, não podemos esquecer de como faremos para organizar a comunicação desta camada, com toda a infra-estrutura para comportar o negócio que o sistema irá gerenciar.
O que geralmente acontece, é que acaba se misturando código de UI com código que realizam outras funções que não é da UI, como código de banco de dados e etc. Além de causar uma grande confusão no código, em cenários como este, a manutenção é um desafio e a evolução é uma lenda; trabalhar desta forma é impraticável.
Existe o que chamamos de Separated Presentation patterns, que tem por objetivo justamente organizar a maneira de como a UI irá se comunicar com outras camadas da aplicação e permitir que o código que executa a lógica da aplicação, seja testável e desacoplado; deixando para a UI, apenas as responsabilidades a ela pertinentes como manipulação de controles, validação de input de dados e repassando para as camadas devidas os demais aspectos da aplicação. Introduzido por Martin Fowler, este tipo de pattern, tem como objetivo, focar no objetivo de separar o domínio da solução, das demais camadas, inclusive da UI, fazendo com que o Domínio da solução desconheça completamente qualquer detalhe referente à apresentação, ou seja, a camada de UI. A figura, abaixo mostra alguns dos Separation Presentation Patterns:
A figura acima ilustra um cenário indesejado, em que uma aplicação web abriga aspectos que não são de sua responsabilidade como log, acesso a dados e acesso a serviços. Veja que em uma aplicação, como a ilustrada pela figura acima, existe uma bagunça generalizada, por acoplar aspectos que deveriam estarem separados e focados em realizar tarefas apenas de sua responsabilidade. A figura abaixo ilustra o cenário ideal e que os patterns presentation, nos auxilia a alcançar:
A idéia de arquiteturas montadas, conforme ilustra a figura acima, é deixar a UI totalmente desacoplada das demais camadas do sistema, deixando a livre para exercer apenas as suas funções. Observe que não há acoplamento rígido para com aspectos como Logging, Serviços, gerenciamento de exceção, e no caso de patterns como Model-View-ViewModel, no caso do silverlight ou WPF, a view não tem nenhum conhecimento do negócio, ela apenas interage com a ViewModel que realiza ações necessárias.
Para uma breve ilustração veja abaixo um pequeno diagrama, de uma aplicação WPF, utilizando Model-View-ViewModel.
Vejamos um código simples de exemplo, desta iteração( um código real poderia ser mais completo, exemplo de código apenas para ilustração do exemplo ).
View:
ViewModel:
Model:
Classe Cliente
A aplicação do MVVM, estabelece uma sintonia entre a UI, a ViewModel e o Model. Os avançados recursos de binding contidos no WPF/Silverlight, permitem uma ligação fácil da UI, com a ViewModel, a ViewModel por sua vez, pode manipular de acordo com a necessidade em questão, o Model como quiser. Veja que no exemplo abordado, a View define como seu DataContext um objeto que foi instanciado declarativamente, e pronto todos os recursos disponibilizados pela ViewMode de clientes, vão poder ser utilizados sem problema; note que quem interage com o repositório, que é um pattern de arquitetura, que realiza as operações de banco de dados, é a ViewModel, ou seja, há uma clara separação de responsabilidades e conceitos. Trabalhando desta maneira, é garantido que a View não tenha nenhum conhecimento do Model, estando livre para manipular seus controles, realizar animações, ou seja, interagir com o usuário. A View não tem nenhuma sobrecarga com responsabilidade que não são suas, e na hora de dar manutenção no sistema, fica muito mais fácil saber onde é necessário ser feita a manutenção, ou na hora de adicionar novas funcionalidades, é muito mais suave também.
Bom pessoal, espero que tenham gostado deste primeiro post, fique ligado, pois este é somente o primeiro, de uma série de posts abordando arquitetura para UI. Após esta série você estará apto a construir aplicações que sofram um impacto menor, com as mudanças que possivelmente possam ocorrer. Abraços e até a próxima.
