EDIT: Essa é a parte 2 de três posts sobre o objetivo 1.1. Você pode conferir a parte 1 aqui (ADO.NET) e a parte 3 aqui (WCF Data Services).
Nesse post vou falar do Entity Framework, a segunda opção de acesso à dados que estará no exame da certificação Microsoft 70-487 dentro do objetivo 1.1, Choose data access technologies. A primeira parte, sobre ADO.NET, está nesse post.
Entity Framework
O EF foi criado para permitir que os desenvolvedores focassem no código da aplicação, não no código necessário para se comunicar com o banco de dados. Essa necessidade surgiu devido às diferenças estruturais entre a programação orientada a objeto e o modelo relacional dos bancos de dados.
Para o exame, é necessário conhecer a estrutura do EF. O model do Entity Framework é dividido em três partes: o CSDL (conceptual schema definition language), que contempla o modelo conceitual, o SSDL (store schema definition language), que trata dos aspectos da estrutura do banco de dados, e o que mapeia as duas partes é chamado de MSL (mapping specification language). As três partes ficam em um único arquivo com a extensão .edmx.
Há dois modos de criar seu modelo conceitual no EF, chamado de Entity Data Model (EDM): Database First, onde você cria seu banco de dados e depois cria seu modelo conceitual, e Model First, onde você primeiro constrói o modelo conceitual e permite que as ferramentas do EF criem a estrutura do banco de dados para você.
Quatro ferramentas estão disponíveis para você criar e modificar seu EDM. São elas:
- Entity Model Designer, item que cria o arquivo .edmx e permite que você manipule quase todos os aspectos do model (criar, atualizar e deletar entidades, criar associações, etc.);
- Entity Data Model Wizard, que é o ponto de partida para a criação do seu EDM no modelo Database First;
- Create Database Wizard é o contrário do item anterior; essa ferramenta permite que você crie primeiro todo o seu modelo conceitual e depois gera o banco de dados necessário (Model First);
- E Update Model Wizard, que permite modificações no EDM após o modelo estar criado.
Nota importantíssima: no exame (e no Visual Studio), o Entity Framework pode ser chamado de ADO.NET Entity Data Model, ou ADO.NET EF. Não se confunda com essa nomeclatura! Ambos estão citando apenas o Entity Framework.
Veja o código para acessar o banco de dados com o EF. Mais detalhes sobre a API do EF serão cobertos no capítulo 2, que é todo dedicado ao Entity Framework.
O EF consegue mapear heranças de duas principais formas: Table per Hierarchy (TPH) e Table per Type (TPT). No TPH, ele cria somente uma tabela que contém todos os derivados de uma herança (criando colunas nullable e uma coluna para indicar o tipo). Já no TPT, para cada filho, uma tabela é criada referenciando o pai com um ID. No EF é possível também criar Tipos Complexos (Complex Types). Numa tabela que tem as colunas DataInicio e DataFim, por exemplo, você pode identificar essas colunas como um tipo complexo e elas se tornarão uma entidade DataRange no seu modelo conceitual.
ObjectContext
No código acima, e nas versões novas do Entity Framework, você geralmente trabalhará com o DbContext (a classe TestEntities). Mas no exame outro (antigo, velho e sujo) modo de usar o EF será cobrado: o ObjectContext. Veja como ele pode ser utilizado abaixo:
O contexto da classe ObjectContext tem uma propriedade chamada ContextOptions que contém 5 propriedades que você pode manipular. São elas:
- LazyLoadingEnabled. Marcada por padrão, essa propriedade controla se as entidades serão carregadas por demanda ou não. O EF faz o Lazy Loading pelas Navigation Properties. Por exemplo, ao carregar um Customer, suas Transactions não são carregadas. Ao iterar pela propriedade Transactions (uma Navigation Property), para cada Transaction na lista, um hit no banco é feito para obter os dados com o LazyLoadingEnabled setado true. Caso seja false, você precisa explicitamente carregar esses dados com o método LoadProperty() ou Include();
- ProxyCreationEnabled determina se classes POCO (plain on commom object) devem ser criadas para dados customizados. Detalhes serão cobertos no capítulo 2 do livro;
- UseConsistentNullReferenceBehavior funciona da seguinte forma: caso seja true e você sete uma Navigation Property que não esteja carregada como null, ao salvar, o EF tentará persistir isso no banco de dados (o que gerará um erro se a coluna não for nullable);
- UseCSharpNullComparisonBehavior muda o jeito que as comparações com null são feitas no banco de dados. Veja a diferença:
Nesse caso, as seguintes queries serão feitas no banco de dados:
SELECT COUNT(*) FROM Account WHERE AccountAlias <> ‘Home’ — Disabled
SELECT COUNT(*) FROM Account WHERE AccountAlias <> ‘Home’ OR AccountAlias IS NULL — Enabled - Por último, UseLegacyPreserveChangesBehavior controle o que acontece quando uma entidade já existe no contexto e é attachada novamente. Por padrão, o EF compara as duas entidades e, se alguma propriedade tiver valor diferente, o estado dessa propriedade vira Modified. Com o UseLegacyPreserveChangesBehavior, o valores diferentes não são copiados.
Você precisa se familiarizar também com as classes geradas pelo ObjectContext, assim como as geradas pelo DbContext (já mostradas acima). Cada entidade do modelo conceitual tem uma classe que herda de EntityObject. Essas classes são decoradas com três atributos:
- EdmEntityTypeAttribute indica que a classe faz parte de um EDM. Contém o namespace e o name da entidade;
- SerializableAttribute. As classes geradas pelo EF precisam ser serializáveis;
- DataContractAttribute é necessário para se trabalhar com WCF (mais detalhes no objetivo 1.5).
As propriedades são decoradas com dois atributos: DataMemberAttribute, para fins de WCF, e EdmScalarPropertyAttribute, que seta duas propriedades (EntityKeyProperty e IsNullable). O código da classe fica assim:
Por Que Entity Framework?
- Com as ferramentas se desenvolvendo cada vez mais, atualizar o modelo é muito menos trabalhoso do que com ADO.NET;
- Você pode focar na lógica do negócio da aplicação, e não com o armazenamento dos dados;
- Atualmente, o EF permite a desacoplação entre o modelo conceitual e o armazenamento dos dados;
- O banco de dados pode ser mudado sem ter a necessidade de reescrever todo o código da aplicação;
- O EF foi pensado para trabalhar em conjunto com WCF.
O próximo post será sobre o último ponto do objetivo 1.1 da certificação, que é sobre o WCF Data Services.
Até mais!