Atenção: esse artigo tem uma palestra complementar. Clique e assista!
Atenção: esse artigo tem um vídeo complementar. Clique e assista!
Neste artigo veremos como criar uma aplicação isolando a camada de Repositório, de forma que possamos trocar de NHibernate para o ADO.NET Entity Framework, e vice-versa. Veremos também como é possível utilizar o SQL Azure nessas duas tecnologias.
Para que serve
Com essas técnicas você estará preparado para substituir o ORM de sua aplicação quando necessário. E você também estará preparado para utilizar o SQL Azure como banco de dados da sua aplicação. SQL Azure que é a solução da Microsoft para armazenamento de dados na nuvem.
Em que situação o tema é útil
A computação na nuvem é uma realidade cada vez mais presente no nosso dia-a-dia. Aos poucos precisaremos portar nossas aplicações para a Nuvem. Na plataforma Microsoft isso significa trabalhar com o Azure. Utilizar ORMs como NHibernate e Entity Framework, permite uma portabilidade entre bancos de dados, e isso também é possível com o SQL Azure, como veremos neste artigo.
Resumo do DevMan
No desenvolvimento de aplicações através da Orientação a Objetos, desde que se começou a falar em ferramentas de ORM (Mapeamento Objeto/Relacional), fala-se também na portabilidade de uma aplicação quanto a diferentes bancos de dados.
Alguns ORMs como o NHibernate permitem essa portabilidade com uma grande quantidade de Bancos de Dados, o que na prática significa que sua aplicação pode trabalhar com SQL Server, Oracle, PostgreSQL, MySQL etc. O ADO.NET Entity Framework da Microsoft, também está começando a seguir esse caminho, e aos poucos está se compatibilizando com as principais databases do mercado.
Agora, com a consolidação de serviços de armazenamento de dados na Nuvem, a portabilidade voltou a ser um assunto importante. Sua aplicação está pronta para ter os dados armazenados na nuvem? O que você vai ter que alterar no seu código para poder usar o SQL Azure?
Veja nesse artigo a importância em se utilizar ferramentas de ORM para garantir a portabilidade entre os bancos de dados do mercado, inclusive o SQL Azure.
Quem nunca quis desenvolver uma aplicação que fosse completamente independente do banco de dados? Independente ao ponto de podermos trocar de um banco de dados para outro, apenas mudando algumas configurações?
Desde que os bancos de dados relacionais se consolidaram no mercado, e a Orientação a Objetos se tornou a linguagem padrão da maioria dos desenvolvedores, falamos de ferramentas de ORM, que fazem justamente a ponte entre os bancos de dados relacionais e a Orientação a Objetos.
Com o surgimento e o aprimoramento das ORMs, surgiu um “subproduto” dessa relação Objeto X Relacional. A questão da portabilidade das aplicações com diferentes bancos de dados. Alguns ORMs, como é o caso do Hibernate do Java e o NHibernate do .NET, sempre ofereceram esse recurso, permitindo que uma aplicação possa trabalhar com diferentes tipos de bancos de dados, apenas trocando algumas configurações.
Essa questão da portabilidade sempre foi tema de discussões acaloradas. A portabilidade com diferentes bancos de dados é importante? É realmente possível manter uma aplicação totalmente isolada do seu banco de dados? Que vantagem eu levo em fazer isso? Não vou perder recursos importantes do meu banco de dados ao manter a aplicação isolada?
Dessa discussão surgiram dois grupos interessantes de indivíduos: Aqueles que modelam suas aplicações baseando-se nos recursos da orientação a objetos, fazendo uso de ORMs, e utilizam um banco de dados apenas como um Repositório da aplicação; e aqueles que criam aplicações acopladas à database, fazendo uso de recursos do banco como Stored Procedures, Triggers, Functions etc., e não encaram o banco de dados como um simples repositório, e sim como parte integrante do comportamento da aplicação.
Para o segundo grupo, portabilidade com diferentes tipos de banco de dados não é um tema importante, já que para trocar de Oracle para SQL Server, é necessário reescrever coisas como Stored Procedures.
Já para o primeiro grupo citado, a portabilidade é uma realidade. A partir do momento em que o banco é apenas um repositório de dados da aplicação, e não utilizamos nenhum recurso específico daquele banco, podemos substituí-lo com maior facilidade.
Como dá pra perceber, a importância da portabilidade com bancos de dados vai depender muito de cada cenário. Depende da natureza do projeto, pessoas e empresas envolvidas. E por isso não dá pra dizer que toda aplicação deve obrigatoriamente ser portável.
Mas hoje, quem manteve suas aplicações independentes de um banco de dados, tem uma vantagem adicional. Essas aplicações podem ser portáveis para o SQL Azure, o banco de dados da Microsoft na Nuvem.
Neste artigo veremos como isso é possível, e ridiculamente simples se você utiliza um bom ORM. Faremos isso com os dois ORMs mais populares na comunidade .NET, o NHibernate e o ADO.NET Entity Framework.
Para elevar ainda mais o nível da portabilidade, veremos que (apesar de algumas limitações) é possível desacoplar a camada de Persistência de uma aplicação, a ponto de podermos trocar de NHibernate para Entity Framework, só mudando algumas poucas configurações. Mãos à obra!
Cloud Computing
Cloud Computing, ou “computação em nuvem” é um termo que vem se tornando cada vez mais presente no desenvolvimento de software. Esse termo se refere à capacidade de compartilhamento de memória, armazenamento e processamento entre servidores interligados pela internet.
Imagine uma rede interminável de servidores, prontos para lhe oferecer serviços de armazenamento e processamento de dados, de forma tal que você não tenha que se preocupar com a disponibilidade de um servidor específico, onde sua aplicação está instalada. Na verdade, sua aplicação ou banco de dados fica “instalada” na nuvem, e não em um único servidor. A arquitetura por trás desse princípio lhe permite uma alta disponibilidade para a sua aplicação, já que funciona como um gigantesco cluster, protegido por milhares de nós.
Gigantes do mercado de software, como Microsoft, IBM e Google, vêm investindo na computação em nuvem já há algum tempo. A Google é uma das pioneiras, que já no início de 2002 começou a oferecer alguns softwares “na nuvem”, como o famoso Gmail para correio eletrônico, além de ferramentas como editores de texto, planilhas eletrônicas, agendas entre outros.
Com o tempo esses “softwares na nuvem” passaram a ser chamados de serviços, iniciando um movimento também muito conhecido, chamado de SaaS ou “Software as a Service”.
A Microsoft, obviamente não ficou atrás nessa corrida pela nuvem, e também passou a oferecer alguns de seus softwares como serviços da nuvem. Um dos mais conhecidos é atual Windows Live, que oferece recursos de correio eletrônico, rede social, armazenamento e Instant Messaging.
A ideia de se oferecer software como serviço vem então ganhando muitos adeptos, e aos poucos estamos nos acostumando a ela, não só como consumidores, mas também como fornecedores destes serviços.
É aqui que entra o Windows Azure, o sistema operacional da Microsoft para a nuvem. Nele, como desenvolvedores, podemos publicar nossas aplicações na nuvem, e oferecê-las para nossos clientes como serviços.
No Windows Azure podemos não só publicar nossas aplicações na rede de servidores da Microsoft, mas também podemos armazenar nossos dados nessa mesma rede. É o SQL Azure, um dos focos deste artigo.
O SQL Azure é o servidor de banco de dados da Microsoft na nuvem, e é muito parecido com o próprio SQL Server da Microsoft, nosso antigo conhecido. Aliás, se você já tem o SQL Server 2008 R2, pode se conectar ao SQL Azure através do SQL Server Management Studio, e fazer uso da interface de gerenciamento de banco de dados que já conhece.
Sendo assim, com o Windows Azure podemos ter uma aplicação na nuvem, “consumindo” a infraestrutura de processamento e armazenamento da Microsoft. Isso nos abre um novo paradigma na forma como consumimos recursos de armazenamento e processamento.
No Windows Azure, nós literalmente consumimos processamento e armazenamento de dados como consumimos energia elétrica nas nossas casas, e é basicamente assim que a Microsoft cobra por esse serviço. O valor a ser cobrado não é mais simplesmente pela hospedagem da aplicação, depende muito mais de quanto sua aplicação usa de processamento e armazenamento.
É esse o cenário que nos encontramos hoje, e que aos poucos precisamos nos preparar para criar soluções que sejam compatíveis com esse ambiente.
Nesse artigo, como já foi dito anteriormente, veremos como utilizar o SQL Azure para armazenamento de dados na nuvem. E a grande novidade é que isso pode ser feito de forma muito simples e fácil, principalmente quando estamos utilizando ferramentas como NHibernate e Entity Framework.
Os serviços da Plataforma Windows Azure, que por muito tempo estiveram em versão beta, agora já estão disponíveis para uso em produção, inclusive aqui no Brasil.
Para que você consiga fazer os testes deste artigo com o SQL Azure, será necessário adquirir um dos planos oferecidos pela Microsoft, no Microsoft Online Services, que você encontra na seção Links. Confira os planos oferecidos pela Microsoft, escolha o seu e assine-o, se assim desejar.
Não vou entrar em detalhes sobre como fazer isso, todas as orientações estão lá no site. Só é muito importante você notar que é um serviço pago, e que não dá para testar o exemplo final deste artigo sem uma assinatura de um destes planos. Então tome bastante cuidado e tenha certeza do plano que está adquirindo, afinal é o número do seu cartão de crédito que terá que ser informado.
Ferramentas de Mapeamento Objeto/Relacional
Acredito que este seja um dos assuntos mais falados e discutidos na comunidade .NET nos últimos anos. A definição mais interessante que eu já ouvi sobre ferramentas ORM está no livro “Applying Domain-Driven Designs and Patterns” de Jimmy Nilsson. Esse, que alias, é um ótimo livro sobre DDD com exemplos em C#.
A capa deste livro é a foto de uma ponte, e essa é a definição de Nilsson dá para ferramentas ORM. Elas são uma “ponte” entre o mundo relacional com o mundo da orientação a objetos.
Atualmente temos duas importantes ferramentas de mapeamento objeto/relacional para a plataforma .NET Framework. A primeira e mais antiga é o NHibernate, a versão .NET do Hibernate para Java. E a mais recente é o ADO.NET Entity Framework, da própria Microsoft, e que ganhou uma nova versão agora com o .NET Framework 4.0.
Jimmy Nilsson, no livro citado anteriormente, fala da importância de termos um Domínio que seja “ignorante” quanto aos mecanismos de persistência da aplicação. Essa é uma questão interessante, e com benefícios tangíveis.
Quando dizemos que temos um Domínio ignorante quanto aos mecanismos de persistência, estamos falando que a camada de domínio da aplicação não tem nenhuma referência à camada de repositório, e se isso for bem feito, significa que você pode trocar facilmente a sua camada de repositório, de uma tecnologia para outra.
Na prática, com isso você é capaz de trocar de Entity Framework para NHiberante (e vice-versa), sem precisar modificar a camada de Domínio. Nesse artigo veremos exatamente como fazer isso, além é claro, de finalizarmos com o acesso ao SQL Azure, com as duas tecnologias citadas acima.
Como veremos mais adiante, o ADO.NET Entity Framework, agora na sua nova versão, nos oferece recursos de modelagem POCO, que de certa forma nos permite chegar ao ponto de isolamento necessário para o exemplo que queremos.
Uma das abordagens do POCO para o Entity Framework é conhecida de POCO Code Only, e com ela fazemos o mapeamento entre nossas entidades e o banco de dados, através de interfaces fluentes. Um mecanismos já conhecido e utilizado no NHiberante, com uma ferramenta chamada Fluent NHibernate (também já explorada em alguns artigos da .NET Magazine).
Com isso você já tem uma ideia do que veremos neste artigo. Vamos agora começar a criar nossos exemplos, começando obviamente pelas entidades do nosso Domínio.
POCO
POCO quer dizer Plain Old CLR Object, e significa que nossas entidades de negócio devem ser as mais simples possíveis, sem nenhuma dependência de ferramentas externas. No POCO mais radical, a classe não herda de ninguém, não implementa nenhum método e possui apenas propriedades que definem a estrutura de propriedades da entidade. Implementações menos radicais também são consideradas POCO, como por exemplo, herdar de uma entidade base, implementar uma interface, ou algum método que realize alguma tarefa específica com o cliente. Tudo isso desde que não haja nenhuma dependência com outras camadas da aplicação e ferramentas externas ao bom e velho CLR. Ou seja, a ideia do POCO é que tenha um modelo de entidades totalmente independente do mundo externo. Mas qual é o benefício disso? Por que se fala tanto em ter uma camada de domínio da aplicação, desacoplada do resto? A resposta é simples. O domínio da aplicação, onde temos o modelo de entidades, assim como a modelagem das regras de negócio, é como o motor de um carro. E nós queremos construir um carro que, quando quebrar uma roda, seja necessário trocar apenas a roda e não o motor. Se você deixar o motor do carro acoplado à roda, toda vez que tiver que trocar a roda terá que trocar o motor também. É isso que acontece em muitas aplicações hoje em dia. Muitos projetos precisam ser refeitos inteiramente porque o domínio da aplicação está espalhado entre as camadas e depende de todo tipo de tecnologia, como banco de dados, ferramentas de persistência e até da camada de apresentação. E como as tecnologias não param de surgir, onde temos novidades praticamente a cada seis meses, é importante que comecemos a planejar nossas aplicações para sobreviver a essas mudanças, senão vamos viver recriando o motor dos nossos projetos, toda vez que surge uma roda melhor no mercado. POCO é uma boa prática voltada para isso. Por si só ele não resolve esse problema, é preciso aliar a ele uma série de boas práticas e princípios que o DDD ensina. Mas ele é uma das principais técnicas para atingirmos este objetivo.
