sexta-feira, 11 de fevereiro de 2011

Criando uma aplicação N-Tier com acesso a dados baseada em classes POCO com Entity Framework 4

Introdução
Para acesso a dados em uma aplicação .NET, utilizamos um “driver” baseado na tecnologia ADO.NET que seja compatível com o banco de dados desejado, como por exemplo o SqlClient para o SQL Server ou o MySqlClient para MySQL. O procedimento é o mesmo para ambos, ou seja, instanciamos uma nova conexão e executamos um comando SqlCommand para enviar a consulta SQL ao banco de dados. Em seguida usamos um SqlDataReader que, através de um laço, podemos preencher um DataTable.
public static DataTable Consulta(string sql)
{
using (var connection = new MySqlConnection())
      {
            using (var command = new MySqlCommand(sql, connection))
            {
var result = command.ExecuteReader();
                        if (result.HasRows)
                        {
                        while (result.Read())
                             {
                                 //
                             }
}
}
}
}

Numa aplicação multi-camadas, precisamos transportar esses dados de uma camada para a outra na forma de classes que representam as entidades, criando classes POCO (plain old clr objects). Essas classes contém apenas propriedades que representam os campos de uma tabela.
public class Pessoa
{
[Key]
public int Id { get; set; }

[StringLength(50)]
public string Nome { get; set; }

public string Email { get; set; }

public int EnderecoId { get; set; }
}

Fazer isso sem um ORM é um trabalho tedioso e repetitivo com muito código suscetível a erros, pois seria necessário criar diversos métodos para cada entidade, ler o retorno da consulta com o SqlDataReader, instanciar a classe desejada, preencher as propriedades dessa classe e retornar.
O papel de um ORM – object relational mapper
Um mapeador objeto-relacional (ORM) é uma ferramenta que facilita o trabalho quando temos a necessidade de recuperar e persistir os objetos (classes) que representam os dados armazenados num banco de dados relacional. Utilizando um ORM, escreveremos pouco ou nenhum comando SQL, pois um bom ORM é inteligente o suficiente para saber quando e como enviar as consultas e comandos ao banco de dados.
Entity Framework
Entity Framework é o mapeador Objeto Relacional (ORM) da Microsoft para o ADO.NET framework. Outros exemplos de ORM são: NHibernate, Abatis, Subsonic, Open Access, Entity Spaces, LighSpeed, Data Objects .NET, BLToolkit, entre outros.
A primeira versão do Entity Framework foi disponibilizada com o .NET 3.5 e o visual Studio 2008. Foi considerada muito limitada se comparado a outros ORM’s que já existiam no mercado e consequentemente não houve uma considerável adoção pelos desenvolvedores.
Já a segunda versão foi disponibilizada no Visual Studio 2010, chamada de Entity Framework 4 (para acompanhar o lançamento do .NET Framework 4) e surgiu com inúmeras melhorias, atendendo a solicitações da comunidade.
Database First, Model First, Code First
O Entity Framework 4 pode criar o modelo a partir de um banco de dados já existente, através de um processo de engenharia reversa (DATABASE FIRST) ou então criar um modelo novo a partir do zero, mapeando propriedades para os campos do banco de dados e o Entity Framework irá gerar o script SQL para a criação do banco, isso tudo de forma visual. (MODEL FIRST).
Estava faltando mais um recurso que já existe há algum tempo em outros ORM’s: A possibilidade de criarmos nossas próprias classes (POCO’s) e mapeá-las para o banco de dados (CODE FIRST).
Atendendo a essa solicitação, foi disponibilizado um pacote de atualização chamado Entity Framework Feature CTP.
No próximo artigo, vou mostrar como trabalhar com Entity Framework 4 usando o modo CODE FIRST.

Um comentário:

  1. Um banco de dados relacional por natureza armazena informações em tabelas, sendo as tabelas definidas por seus campos, cada campo guardando dados de um determinado tipo. Como esses dados que são recuperados do banco não são objetos de nossa aplicação e sim objetos do banco de dados, há o chamado conflito de impedância (impedance mismatch) entre a aplicação que construímos e o banco de dados. (Veja um artigo interessante sobre o assunto) http://www.fernandoamaral.com.br/Default.aspx?Artigo=17

    "Object-Relational Impedance Mismatch" é o "conflito de impedância no mapeamento objeto-relacional" / resistência (diferença técnica) sutil entre modelos objeto-relacionais".

    Para reduzirmos essa diferença entre a aplicação que utiliza orientação a objeto e o banco de dados que é relacional, criamos bibliotecas de funções BLL's e escrevemos código SQL para recuperar os dados, instanciando classes que representam essas tabelas, e preenchendo as propriedades das classes com os valores de cada campo, geralmente seguindo um padrão de design chamado DAO. Dessa forma, as telas de nossa aplicação fazem utilização de objetos e não se comunicam diretamente com o banco de dados.

    Uma maneira mais produtiva (do que ter todo esse trabalho manual e tedioso) é utilizar um ORM como NHibernate, Entity Framework, SubSonic, BlToolkit, DataObjects.NET, entre outros. Veja mais opções em http://ormeter.net/.

    A principal função de um mapeador objeto-relacional (ORM) é materializar na forma de objetos/classes as informações recuperadas da fonte de dados. O Entity Framework faz muito bem esse papel.

    ResponderExcluir