[Artigo recomendando para Visual Studio 2008;SP1]
Com lançamento do novo modelo de acesso a dados na plataforma .NET conhecido como ADO.NET ganhamos um o acesso a dados nativo de alto desempenho ao SQLServer e Oracle superando os modelos tradicionais de outras plataformas.
O modelo do ADO.NET trouxe dois modos principais de acordo com o tipo de conexão estabelecida com o banco de dados. O primeiro conhecido como DataReader de alta performance destinado ao acesso conectado e modelo DataSet destinado ao modelo desconectado que funciona numa estrutura muito parecida ao banco de dados de forma off-line permitindo conter tabelas, relacionamentos, chaves primarias e manipulação das informações baseadas em coleção de objetos.
Com evolução da plataforma .NET passamos a contar com o modelo de acesso a dados baseado no TableAdapter que em conjunto com DataSet que já permitiu criar de forma rápida uma camada de CRUD (Create, Read, Update, Delete) para acesso a dados já estabelecendo o primeiro contato com modelo objeto relacional O/R dispensando a necessidade de se fazer código ADO.NET manualmente.
Com o lançamento do .NET 3.5 foi incorporado ao mesmo o LINQ (Language Integrated Query) que oferece uma importante característica no .NET com a possibilidade de fazer consultas em cima de objetos.
Acompanhando a evolução da plataforma .NET agora temos a disposição o modelo ADO.NET Entity Framework que vai oferecer o mapeamento objeto relacional (O/R) de forma a permitir o mapeamento das tabelas do banco de dados como objetos para abstrair o acesso a dados deixando para o desenvolvedor que já conhece orientação a objetos mais um grande mecanismos de acessar banco de dados sem precisar conhecimento aprofundado de banco de dados e de T-SQL (Trasact SQL).
Com o LINQ to Entity Framework você poderá fazer mapeamento para diversas bases de dados (SQLServer, Oracle, DB2, MySql, PostgreSQL, SQLite, VistaDB, Informix, Sybase … ) assim como para outras fontes como XML e serviços.
O primeiro passo é adicionar um novo mapeamento Entity Data Model que é arquivo
XML com as informações do banco de dados e das classes que será nossa visão. Para iniciar vá ao Visual Studio 2008 SP1 e adicione um novo arquivo Entity Data Model cuja extensão é “*.edmx” conforme figura 01 e figura 02.
Figura 01 – Criando Entity Data Model.
Após adicionar o arquivo você será direcionado pelo assistente para conectar no seu banco de dados e fazer o mapeamento escolhendo as tabelas, views, procedures, funções
Figura 02 – Assistente para mapeamento.
Figura 03 – Selecionando objetos para mapeamento.
Após avançar terá como resultado o diagrama de classes conforme a figura 04.
Figura 04 – Diagrama de classe representando o mapeamento
Todas as classes mapeadas estarão dentro do Entity Data Model de nome “Banco01Model” conforme figura 05.
Figura 05 – Visualização do Molde Browser
Com diagrama criado conforme figura 04 você já pode usar o LINQ para fazer todas operações de consultas em seus objetos. Para um primeiro testes você pode adicionar uma nova pagina e arrastar um controle do tipo GridView e incluir o seguinte código de teste no Page_Load conforme exemplo na figura 06.
Figura 06 – Consultando Entity Framework usando LINQ to Entity.
Conforme você pode observar no simples código de exemplo estamos fazendo uma consulta usando LINQ na coleção de objetos Clientes e armazenando o resultado no objeto consulta. Depois estamos fazendo a vinculação com um GridView.
Para o desenvolvedor ele não vai precisar escrever código .NET para acessar o banco de dados e no lugar do T-SQL para as consultas vai usar o LINQ que é totalmente integrado
ao IntelliSense do Visual Studio. Isso representa um enorme ganho de produtividade.
Você também vai poder vincular o GridView diretamente pelo IDE usando criando um novo Entiy Data Source conforme figura 07.
Figura 07 – Criando Entity Data Source.
Figura 08 – Configurando Entity Data Source
Agora o próximo passo é configura o GridView para paginar e atualizar registros conforme figura 09. 
Figura 09 – Configurando GridView
Conforme você conferiu nesse artigo o Linq to Entity abre um novo leque de oportunidades na construção de aplicações baseadas em orientação a objet
os usando o novo modelo de mapeamento objeto relacional que visa abstrair todo código de acesso a dados colocando o desenvolvedor um novo patamar de produtividade.
Comente esse artigo e não se esqueça de uma frase importante “Não tem que ser difícil”. Até a próxima!
—————————————————————————————————-
Entre em contato com a 2PC PROFESSIONAL CONSULTING para consultoria e treinamentos sobre Visual Studio 2008.
Relacionados:
já estou trabalhando com Entity Framework desde versão BETA 2 do visual Studio..
Entity Framework ganhamos muita produtividade.
Pleased to see your blog! http://www.slideshare.net/jkljkl520/drinking-water-filter wish you have a great day! http://www.scribd.com/doc/29082722/Drinking-Water-Filter Thanks for this article http://www.docstoc.com/docs/31977803/Drinking-water-filter I will come back again.
I hope you have a http://ezinearticles.com/?Hypnotherapy-Assists-Cancer-Patients&id=3339375 day!
Hey admin, good afternoon. Gorgeous post. You have gained a completely new fan. Pleasee continue this great work and I look forward to more of your gorgeous posts. God bless, !
Do you have any more info on this?
Ramon,
Continuando especificamente sobre mapeamento e entidades.
Eu tenho a seguinte classe:
Public Class Pedido
Private _PedidoId As Nullable(Of Integer)
Private _Fornecedor As Fornecedor
Private _DataPedido As Nullable(Of Date)
Private _PedidoItens As List(Of PedidoItem)
Private _Estado As Estado
(…) ‘Aqui vão as declarações de
End Class
Eu consigo mapear as propriedades dela para uma tabela? O que eu estou entendendo é que hoje eu teria que criar uma Entity que iria ficar trafegando pelas minhas camadas com os dados.
Porém no meu modelo, em cada classe eu tenho comportamentos, etc…
Hoje a estratégia do EF, para mim, fere os princípios da OOP. Assim como o Dataset fere!
Poxa, a MS hoje esta desenvolvendo um framework MVC para utilizar patterns etc… E na camada de dados faz isso?
Suas dúvidas são interessantes. O LINQ to SQL é especifico para SQL e foi FEITO para funcionar dessa forma. Nunca foi diferente!
Com o LINQ to Entity Framework você poderá fazer mapeamento para diversas bases de dados (SQLServer, Oracle, DB2, MySql, PostgreSQL, SQLite, VistaDB, Informix, Sybase … ) assim como para outras fontes como XML e serviços.
Ou seja, você vai usar o Entity para “tudo” e principalmente pra cenários complexos não atentidos pelo LINQ to SQL.
Pense no entanto que você ainda não instalou o SP1, pois nesse momento você está testando o primeiro beta público.
Quanto a Microsoft. Se você pesquisar a plataforma .NET não existe nada fora do padrão e a questão de uso dos wizard é opcional. Você sempre pode usar diretamente via código se assim achar necessário, na vedade não precisa nem de Visual Studio rsrsrs. Você pode herdar e entender se assim achar necessário. Nada melhor para referênciar isso que é as várias ramificações de LINQ to **** que o pessoal da comunidade está implementando!
É importante reforçar pra você que uma plataforma BETA é liberada justamente para você promover adoção antecipada e ir conhecendo as funcionalidades à medida que o produto vai evoluindo. Isso não garante que toda especificação do produto já vai está disponível na primeira versão.
Continue mandando suas dúvidas. Até a próxima e vamos de Entity!
Ramon,
Sem reclamações quanto ao seu artigo, entendi ser uma introdução. É que estou com sede de informações.
Vamos lá:
- Estratégia do EF entendida, o EF vai ser uma camada de serviços de dados, já li que no futuro ele irá suportar fontes de dados como WebServices, abstraindo isso para o desenvolvedor.
- Mudança de BD: (Especificamente em relação ao Linq To SQL) quando eu decoro minha classe e propriedades com atributos como Table, eu amarro as minhas classes modelo com o Linq To SQL, amanhã se eu quero mudar a camada Linq To SQL para NHinbernate ou se eu quero simplesmente trocar o BD de SQL Server para Firebird não fica tão simples. O NHibernate já permite simplesmente eu trocar um BD SQL Server por um Oracle, Firebird ou “whatever” já que ele abstrai nele a camada DAL! A minha camada de modelos não é afetada.
- Realmente o EF hoje permite juntar duas tabelas, o que não acontece no Linq To SQL, ponto para o EF!
- Estratégia Linq To Entity: Estou ansioso por isso, só espero que isso não seja aquelas coisas que a MS faz que fica extremamente fechado, totalmente amarrado aos wizards dela e pior sem seguir os padrões! O que eu esperava quando instalei o SP1 foi encontrar no mínimo um O/R para SQL Server, onde eu pudesse jogar minha camada DAL fora e mapear a minha camada Modelo, mas não é o que acontece hoje.
O objetivo nesse momento foi nivelar nesse artigo uma visão bem introdutória ao Entity Framework que está agora em seu primeiro beta público. A estratégia do LINQ to Entity é muito mais abrangente avançando o nível de serviços e não tão somente dados relacionais.
Não entendi o que você chama de mudar de banco de dados?
A integração do Entity Framework com o Visual Studio é total o que traz ao desenvolvedor por meio as consultas realizadas com o LINQ to Entity o isolamento da fonte de dados seja ela qual for. O Entity traz diversos recursos que não tem hoje no LINQ to SQL como o mapeamento de duas tabelas para uma mesma classe.
Mais novidades em breve. E pense com um pouco mais de calma, a palavra do momento é o “LINQ to Entity” e a Microsoft está investido muito nessa estratégia e não é à toa.
Ramon,
O artigo demonstra a criação de entidades com o EF, o que ficaria “quase igual” a se criar DataTables e DataSets.
Eu estou tentando descobrir como fazer o mapeamento O/R de classes existente no meu código, acho que essa é a grande questão no momento.
Você tem essa resposta? O EF faz isso neste momento ou é uma feature a ser implantada no futuro?
Se o EF se propõe a trabalhar somente dessa forma não vejo o por que de sair de um O/R existente e funcional, NHibernate por exemplo (que também estou analisando no momento e cogitando seriamente em usar) para usar o EF; não vejo ganho, neste momento, no uso do EF.
Aliás, o Linq To SQL me parece até melhor, apesar de também não ser uma solução de O/R, já que não posso trocar o banco e não isolo a camada de DAL devidamente.