Arquitetura Para UI

   

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:

 

 

    Cada um dos patterns mostrados na figura anterior, pode ser aplicado em uma variedade muito grande de cenários, não importando se sua UI, é um aplicativo Windows forms, Console, WPF, silverlight ou ASP.NET. Observe a figura abaixo:

 

 

 

 

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.