Atenção: esse artigo tem uma palestra complementar. Clique e assista!
Das maneiras de se trabalhar com Silverlight, do ponto de vista arquitetural, ou seja, qual a melhor arquitetura de aplicação. O que é e como o se aplica o padrão Model-View-ViewModel a esse tipo de tecnologia.
Para que serve
Padrões de arquitetura são conceitos essenciais para estruturar o projeto para que fique simples e fácil de desenvolver e o mais importante, fácil de dar manutenção posteriormente. Também, a separação dos conceitos fica clara e logicamente correta, o que significa que, por exemplo, não terá nada de regra de negócio na interface do sistema.
Em que situação o tema é útil
Grandes empresas procuram criar os seus projetos nos padrões atuais e que facilitam todo o processo de desenvolvimento e manutenção. Então, conhecer esses padrões de arquitetura e aplicá-los não é uma opção, mas quase uma obrigatoriedade quando se fala de software de qualidade.
Silverlight e MVVM
As novas tecnologias como o Silverlight, nos permitem separar cada vez mais os conceitos que compõe um projeto, como interface com o usuário, regra de negócios e acesso a dados. Essa separação faz uso de alguns padrões de arquitetura. O objetivo deste artigo é mostrar o que o Silverlight oferece para se trabalhar com o padrão mais utilizado para ele atualmente, que é o MVVM (Model-View-ViewModel). Através de um pequeno sistema será explorada a definição das camadas envolvidas, classes de apoio e a aplicação em si.
Antigamente, os projetos de programação eram limitados na questão de arquitetura, ou seja, o máximo que poderia fazer era gerar um executável para o sistema inteiro, não permitindo a separação dos conceitos no que hoje é se chamado de camada.
Um projeto pode ser divido em várias partes no ponto de vista conceitual: interface com o usuário, regras de negócios e acesso a dados, onde cada uma dessas partes pode ser dividida em várias partes também, mas vendo genericamente, são estes os pontos. Cada parte é chamada de camada. Muitas vezes já se ouviu falar de trabalhar em camadas, por que hoje em dia isso é o que há de melhor na estruturação de projetos.
Essa estruturação nos projetos causam facilidades durante o desenvolvimento do mesmo. Como por exemplo a melhor divisão de trabalho na equipe, e posterior à sua produção, a manutenção do sistema será muito mais rápida, pois a identificação do problema será feita com maior facilidade.
Porém, a arquitetura do sistema depende da tecnologia que será usada. Desde o surgimento do .NET foi possível dividir, pelo menos nas camadas mais genéricas (interface, negócios e acesso a dados). Porém conforme as tecnologias foram melhorando e foram oferecendo recursos inovadores, como por exemplo o avanço do DataBinding, que é a interligação dos dados, permitiu-se que as camadas pudessem ter uma estrutura diferente, porém sempre mantendo a mesma essência.
O Silverlight faz partes dessas tecnologias que, baseado nos modelos antigos de arquitetura, permitiu que outro fosse criado utilizando o que a tecnologia oferece de melhor. O objetivo deste artigo é mostrar como aplicações Silverlight podem se estruturar no padrão de arquitetura mais utilizado pra esta tecnologia atualmente, o MVVM, que é um padrão que pode ser utilizado também para aplicações WPF.
Trabalhando em camadas
Com o avanço das linguagens e tecnologias, a estruturação dos projetos sofreram muitas mudanças. O objetivo dessas mudanças sempre foram separar os conceitos que compõem um projeto, onde estes principais conceitos são a interface com o usuário, as regras de negócio e o acesso a dados.
O objetivo disso é, em primeiro lugar, manter as regras de negócio do sistema em um único lugar onde independente de quem for acessar, acesse sempre as mesmas regras, e não que cada vez que seja utilizada uma regra, a mesma seja criada a regra novamente. Contextualizando: uma solução pode ter o projeto Class Library representando toda regra de negócio. Assim, independente se for um Windows forms ou um web service, serão as mesmas regras para quem solicitar tal operação.
Em segundo lugar, a equipe pode se dividir para desenvolver o projeto. Enquanto uma equipe desenvolve a interface do sistema, seja ela qual for, Silverlight, Windows Forms ou até um Console Application, não necessitará saber o que o método que inclui um cliente, por exemplo, faz. Somente basta saber que quando chamar o método que faz essa operação, vai incluir o cliente em algum lugar, seja em XML ou em um banco de dados da Oracle.
E, um teórico terceiro ponto, seria a possibilidade de trocar a maneira de inclusão de dados. A camada de acesso a dados também é separada, podendo ser trocada caso for necessário. Porem é muito raro este caso acontecer, pois geralmente, antes de começar um projeto é decidido como os dados serão armazenados e quase não ocorre mudança nisso. Mas se acontecer, a arquitetura permitirá as alterações já que a camada de negócios, que chama a camada de dados, só entenderá que as operações de dados serão chamadas, independente a forma de implementação da mesma.
A Figura 1 ilustra a sequência na ordem que as operações são chamadas entre as camadas, ou seja, interface chama negócios, que por sua vez, chama a camada de dados e o caminho inverso também é válido.
Figura 1. Sequência das operações nas camadas
As informações vão trafegando desde a interface até a camada de dados, podendo-se fazer várias operações com os dados antes de gravá-los no banco de dados. Dessa forma por exemplo, comandos SQL ficam somente na camada de dados e não na interface, como antigamente era frequentemente feito.
Padrões de arquitetura
A partir de agora, será apresentado um dos principais padrões utilizado para separação de interface de usuário, o Model-View-ViewModel MVVM, descrevendo a estrutura e citando para qual tipo de projeto ele pode ser utilizado.
...
