Este é um post disponível para assinantes MVPEste post também está disponível para assinantes da .net Magazine DIGITAL ou para quem possui Créditos DevMedia. Clique aqui para saber mais!
dê seu feedback
post favorito
ADO.NET Entity Framework 4 - .net magazine 73
Veremos neste artigo algumas formas de se fazer uma modelagem com objetos POCO (Plain Old CLR Objects), onde podemos criar nossas próprias classes e utilizá-las como classes de persistência com a versão 4 do ADO.NET Entity Framework (conhecida também como EF4, ou também EFv4), no Visual Studio 2010 RC.
.net Magazine 73
[Artigo já está disponível no Leitor Digital DevMedia®. Clique aqui para acessá-lo]
> Clique aqui para ler todos os artigos da .net Magazine 73
[Artigo já está disponível no Leitor Digital DevMedia®. Clique aqui para acessá-lo]
> Clique aqui para ler todos os artigos da .net Magazine 73
ADO.NET Entity Framework 4
POCO – Suas classes de negócio mais independentes
Resumo do DevMan
Uma das reclamações mais recorrentes da primeira versão do ADO.NET Entity Framework é que ele não permite uma modelagem POCO, onde definimos nosso modelo de entidades em classes que só dependam de recursos nativos do .NET.
No ADO.NET Entity Framework precisamos criar um diagrama “visual” das nossas entidades em um modelo EDMX. E esse modelo é que internamente irá gerar o código das nossas entidades. Isso gera uma dependência muito forte entre as entidades e o ADO.NET Entity Framework, ferindo um dos princípios mais básicos do DDD, que nos diz para isolarmos o modelo de entidades de qualquer tipo de implementação.
Neste artigo você verá que na versão 4 do ADO.NET Entity Framework agora podemos fazer uma modelagem utilizando POCO’s, atendendo assim a algumas regras do DDD.
POCO quer dizer Plain Old CLR Object, e significa que nossas entidades de negócio devem ser o mais simples possível, sem nenhuma dependência de ferramentas externas. Confira um exemplo de como é uma classe modelada no estilo POCO na Listagem 1.
Listagem 1. Simples exemplo de classe POCO
namespace EFv4Poco.Dominio
{
public class Cliente
{
public int ID { get; set; }
public string Nome { get; set; }
public string Endereco { get; set; }
public string Telefone { get; set; }
}
}
Veja que a classe não herda de ninguém, não implementa nenhum método e possui apenas propriedades que definem a estrutura de um cliente. Esse é o POCO mais radical que se pode fazer. 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. 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.
A primeira versão do ADO.NET Entity Framework, que surgiu no Service Pack 1 do .NET Framework 3.5, não permite uma modelagem POCO. Com ele nosso modelo de entidades, e consequentemente o domínio da aplicação, fica fortemente acoplado ao Entity Framework. Isso é ruim se você levar em conta que o Entity Framework é uma “roda”, e que “rodas” melhores certamente surgirão no futuro.
Para aqueles que acreditam que o Entity Framework não precisará ser substituído no futuro, acoplar seu domínio a ele talvez não seja um problema, e uma implementação POCO não seja necessariamente importante. Mas a história nos mostra que novos “Entity Frameworks” surgirão, e que é bem melhor tratá-los como rodas e não como parte do motor.
A alternativa mais lógica para quem procura uma arquitetura desacoplada é o NHibernate, que desde o seu surgimento permite uma modelagem ao estilo POCO, e portanto permite a modelagem de um domínio totalmente isolado do restante da aplicação.
E é também para atender a essa necessidade que o ADO.NET Entity Framework 4.0 nos traz recursos para uma modelagem POCO. Vamos ver nas próximas páginas algumas formas de se fazer uma modelagem POCO com o EFv4.
Nota do DevMan
Junto com a nova versão do .NET 4.0 / Visual Studio 2010, surge o ADO.NET Entity Framework 4 (EFv4 para simplificar). Mas essa não é a quarta versão da ferramenta, e sim a segunda. A primeira versão do EF surgiu no .NET 3.5 Service Pack 1, e agora a segunda versão está sendo chamada de “versão 4”. A Microsoft diz que esse pulo de 3 versões é para simplesmente “alinhar” o número das versões de todos os produtos deste último lançamento da plataforma.
"
ATENÇÃO! A exibição deste artigo foi interrompida.
Este é um post disponível para assinantes MVP
POCO – Suas classes de negócio mais independentes
Resumo do DevMan
Uma das reclamações mais recorrentes da primeira versão do ADO.NET Entity Framework é que ele não permite uma modelagem POCO, onde definimos nosso modelo de entidades em classes que só dependam de recursos nativos do .NET.
No ADO.NET Entity Framework precisamos criar um diagrama “visual” das nossas entidades em um modelo EDMX. E esse modelo é que internamente irá gerar o código das nossas entidades. Isso gera uma dependência muito forte entre as entidades e o ADO.NET Entity Framework, ferindo um dos princípios mais básicos do DDD, que nos diz para isolarmos o modelo de entidades de qualquer tipo de implementação.
Neste artigo você verá que na versão 4 do ADO.NET Entity Framework agora podemos fazer uma modelagem utilizando POCO’s, atendendo assim a algumas regras do DDD.
POCO quer dizer Plain Old CLR Object, e significa que nossas entidades de negócio devem ser o mais simples possível, sem nenhuma dependência de ferramentas externas. Confira um exemplo de como é uma classe modelada no estilo POCO na Listagem 1.
Listagem 1. Simples exemplo de classe POCO
namespace EFv4Poco.Dominio
{
public class Cliente
{
public int ID { get; set; }
public string Nome { get; set; }
public string Endereco { get; set; }
public string Telefone { get; set; }
}
}
Veja que a classe não herda de ninguém, não implementa nenhum método e possui apenas propriedades que definem a estrutura de um cliente. Esse é o POCO mais radical que se pode fazer. 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. 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.
A primeira versão do ADO.NET Entity Framework, que surgiu no Service Pack 1 do .NET Framework 3.5, não permite uma modelagem POCO. Com ele nosso modelo de entidades, e consequentemente o domínio da aplicação, fica fortemente acoplado ao Entity Framework. Isso é ruim se você levar em conta que o Entity Framework é uma “roda”, e que “rodas” melhores certamente surgirão no futuro.
Para aqueles que acreditam que o Entity Framework não precisará ser substituído no futuro, acoplar seu domínio a ele talvez não seja um problema, e uma implementação POCO não seja necessariamente importante. Mas a história nos mostra que novos “Entity Frameworks” surgirão, e que é bem melhor tratá-los como rodas e não como parte do motor.
A alternativa mais lógica para quem procura uma arquitetura desacoplada é o NHibernate, que desde o seu surgimento permite uma modelagem ao estilo POCO, e portanto permite a modelagem de um domínio totalmente isolado do restante da aplicação.
E é também para atender a essa necessidade que o ADO.NET Entity Framework 4.0 nos traz recursos para uma modelagem POCO. Vamos ver nas próximas páginas algumas formas de se fazer uma modelagem POCO com o EFv4.
Nota do DevMan
Junto com a nova versão do .NET 4.0 / Visual Studio 2010, surge o ADO.NET Entity Framework 4 (EFv4 para simplificar). Mas essa não é a quarta versão da ferramenta, e sim a segunda. A primeira versão do EF surgiu no .NET 3.5 Service Pack 1, e agora a segunda versão está sendo chamada de “versão 4”. A Microsoft diz que esse pulo de 3 versões é para simplesmente “alinhar” o número das versões de todos os produtos deste último lançamento da plataforma.
"
ATENÇÃO! A exibição deste artigo foi interrompida.
Este é um post disponível para assinantes MVPEste post também está disponível para assinantes da .net Magazine DIGITAL ou para quem possui Créditos DevMedia. Clique aqui para saber mais!
7 COMENTÁRIOS
Marcello Bacos Moreno
Estou seguindo o tutorial, por enquanto encontrei o seguinte erro de sintaxe :
string inputFile = @"..EFv4Poco.PersistenciaLocadora.edmx";
O correto seria :
string inputFile = @"..\EFv4Poco.Persistencia\Locadora.edmx";
string inputFile = @"..EFv4Poco.PersistenciaLocadora.edmx";
O correto seria :
string inputFile = @"..\EFv4Poco.Persistencia\Locadora.edmx";
[há +1 ano] -
Responder
Devmedia - Equipe De Moderação
Marcello,
obrigado pelo aviso. Já foi consertado.
[há +1 ano] -
Responder
Eduardo Felipe Melo De Siqueira
Está dando um erro aqui no meu de FixupCollection,
Error 16 The type or namespace name ''''FixupCollection'''' could not be found (are you missing a using directive or an assembly reference?) C:\Users\eduardo.melo\documents\visual studio 2010\Projects\EFv4Poco\EFv4Poco.Dominio\Produtora.cs 53 51 EFv4Poco.Dominio
alguém poderia me ajudar ?
Error 16 The type or namespace name ''''FixupCollection'''' could not be found (are you missing a using directive or an assembly reference?) C:\Users\eduardo.melo\documents\visual studio 2010\Projects\EFv4Poco\EFv4Poco.Dominio\Produtora.cs 53 51 EFv4Poco.Dominio
alguém poderia me ajudar ?
[há +1 ano] -
Responder
Thiago Dutra Chiarato
Boa Noite, no ponto em que esta descrito
"Para fazer isso, precisamos literalmente mover o template Locadora.Context.tt do projeto EFv4.PErsistencia para o projeto EFv4.Dominio.
O correto não seria Mudar o Locadora.tt ao invés do Locadora.Context.tt ?
"Para fazer isso, precisamos literalmente mover o template Locadora.Context.tt do projeto EFv4.PErsistencia para o projeto EFv4.Dominio.
O correto não seria Mudar o Locadora.tt ao invés do Locadora.Context.tt ?
[há +1 ano] -
Responder
Devmedia - Equipe De Moderação
Realmente o correto é mover o arquivo Locadora.tt e não o Locadora.Context.tt. O artigo ficou com essa pequena falha.
[há +1 ano] -
Responder
Marcelo De Oliveira Cardozo
Quando eu aciona o debug no VS ele apresenta a seguinte mensagem após iniciar o Main.
TypeLoadException was unhandled.
Could not load Type 'Microsoft.Data.Objects.ContextBuilder`1' from assembly 'Microsoft.Data.Entity.Ctp, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089'.
Como resolver isto?
TypeLoadException was unhandled.
Could not load Type 'Microsoft.Data.Objects.ContextBuilder`1' from assembly 'Microsoft.Data.Entity.Ctp, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089'.
Como resolver isto?
[há +1 ano] -
Responder
Luiz Agnelo C. Maia
Você precisa referenciar a biblioteca Microsoft.Data.Objects
[há +1 ano] -
Responder
Você está em:
canal .net
Publicidade
Rodrigo Sendin
Space do autor
é Arquiteto de Sistemas e trabalha com desenvolvimento de Software há mais de 13 anos. Tecnólogo formado pela FATEC de Americana e MCP .NET.
Space do autor
0
0
