Obs.: Na edição da Revista PROGRAMAR nº 26, de Dezembro de 2010, abordei a utilização do modelo database-first, mostrando como criar as entidades e como efetuar algumas operações CRUD (acrônico para Create, Read, Updade e Delete).
Neste artigo, abordaremos de uma forma geral como utilizar as restantes abordagens: model-first e code-first.
Abordagem Model-First
Esta abordagem permite-nos criar o nosso modelo conceitual, usando o Visual Studio, e depois, com base neste, criar a base de dados. Após a criação do modelo, é criada a DDL (Data Definition Language), que será guardada num arquivo *.sql e que nos permite então criar a base de dados.
Existem algumas vantagens desta abordagem, pois é uma forma de trabalhar na qual temos o nosso modelo e não nos precisamos nos preocupar com a base de dados ou como esta irá ser construída. Não necessitamos também de ter conhecimentos muito específicos de bases de dados (como criar tabelas, relações, etc.), sendo tudo feito no Visual Studio de uma forma simplificada. Além disso, ficamos com o DDL que nos permite criar a base de dados em qualquer altura (por exemplo após a instalação da aplicação).
Neste exemplo será criada uma Class Library, permitindo assim isolar a lógica de acesso a dados e, caso seja necessário, reutilizar em diferentes projetos.
Para a criação do nosso modelo, numa abordagem model-first, criamos um novo projeto no Visual Studio 2010 definindo como Framework a 4.0, e com o nome “RevistaClassLibrary”.
NOTA: Após o projeto criado, podemos apagar a classe que aparece por defeito (Class1 .vb), pois não será necessária.
Adicionamos um novo item, recorrendo aos templates no separador Data - ADO.NET Entity Data Model. Esta opção, que iremos definir com o nome RevistaModel.edmx, irá criar um arquivo *.edmx que irá representar o nosso modelo.
Este *.edmx é um arquivo XML que define o modelo conceitual, o modelo de dados e as relações entre as diferentes entidades. Na seguinte opção, podemos escolher se queremos gerar um modelo de uma base de dados, como foi abordado no artigo anterior na Revista PROGRAMAR edição 26, ou criar um modelo vazio. Iremos escolher a segunda opção – Empty model.
Com o nosso documento criado, ainda vazio, existem duas ferramentas importantes para o desenvolvimento do modelo: a Toolbox, que tem agora objetos específicos para o Entity Framework, e o Model Browser, que permite explorar o nosso modelo. Existem duas formas de criar o modelo: através da Toolbox, já referida anteriormente, ou clicando com o botão direito do mouse sobre a janela aberta. A segunda opção é mais simples de utilizar.
Ainda antes de iniciarmos a construção do nosso modelo conceitual, existe uma opção interessante, se olharmos para a janela das propriedades: Pluralize New Objects. Esta opção, caso esteja definida como verdadeira (True), irá automaticamente tentar pluralizar os nomes das entidades. Infelizmente não funciona na versão Portuguesa, mas, se utilizarmos nomes em Inglês, é muito interessante.
Para este exemplo, vamos criar um modelo muito simplificado que permita representar as edições da revista PROGRAMAR. Vamos criar duas entidades que vão representar os artigos e os seus autores.
Por defeito, quando criamos uma nova entidade, ele inclui a criação de um identificador (chave primária), que podemos, caso não seja necessário, retirar. Não define também nenhuma herança, podendo esta ser indicada no “Base Type”, ou seja, podemos definir heranças entre entidades, selecionado a entidade correspondente. Adicionando algumas propriedades, e definindo os tipos de dados corretos (ex. DataNascimento = DateTime ou Edicao = Int32), rapidamente construímos os modelos para representar as edições da revista.
Note que por defeito, quando é adicionada uma nova propriedade à entidade, o tipo de dados está definido como String, com um tamanho de armazenamento máximo para este tipo de dados (2^3-1) - nvarchar(max). Podemos e devemos alterar, caso seja necessário, assim como explorar e ajustar as restantes propriedades, como por exemplo, o tamanho máximo para uma String (Max Lenght), qual o valor por defeito (DefaultValue), se permite valores nulos (Nullable), etc.
E já estão então criadas as duas entidades e neste momento só nos falta definir a relação entre ambas. Como um artigo pode ter vários autores e um autor pode ter vários artigos, necessitamos criar uma relação muitos para muitos (many-to-many).
Ao adicionarmos a relação entre as entidades, usando a opção Association, é criado um novo campo no final, designado por Navigation Property, que irá permitir a navegação entre as entidades. Podemos alterar o nome da propriedade de navegação (caso seja necessário).
E lá está! Este foi o último passo para criar o modelo conceitual e é agora hora de gerar a base de dados. Para o fazer, será necessário clicar com o botão direito do mouse sobre o editor e selecionar a opção “Generate Database from Model”.
Irá então aparecer um wizard que nos permite selecionar uma ligação já existente ou criar uma nova.
Selecionada a ligação que pretendemos, irá ser gerado um script DDL que permitirá, após execução, criar uma base de dados em SQL Server 2005, 2008 e Azure.
Reparem que apenas criamos duas entidades (autores e artigos), mas como definimos uma relação muitos para muitos (many-to-many), é necessário utilizar uma tabela auxiliar. O EF fez isso por nós e no SQL ficamos então com três tabelas, como se pode ver na seguinte imagem:
Se no Solution Explorer escolhermos a opção “Show All Files”, podemos ver que o nosso modelo (*.edmx) tem um arquivo com a extensão *.vb (neste caso RevistaModel.Designer.vb). Neste arquivo podemos ver e o código que está por trás do nosso modelo conceitual, e efetuar eventualmente, algumas alterações.
Ao adicionarmos um novo projeto a esta solução (*.sln), que irá representar a camada de apresentação (Presentation Tier), ou usando externamente, é necessário adicionar referências à classe que criamos (separador Project) e a System.Data.Entity (separador .NET). É necessário também copiar a Connection String, que se encontra no arquivo de configuração (app.config ou web.config), uma vez que esta foi definida na Class Library, no momento de ligação à base de dados.
Connection String tem um conjunto de metadata que indica a localização do arquivo de CSDL (Conceptual Schema Definition Language), do SSDL (Store Schema Definition Language) e do MSL (Mapping Schema Language). O asterisco (*) indica que estes ficaram embebidos no arquivo binário, podendo isto ser alterado, indicando, nas propriedades do modelo conceitual, que o Metadata Artifact Processing não está Embed in Output Assembly, mas sim Copy to Output Directory. Indica depois a ligação propriamente dita à base de dados.
Abordagem Code-First
Esta é outra abordagem que podemos utilizar em Entity Framework, além das já referidas neste artigo (model-first) e no artigo da edição 26 da revista PROGRAMAR (database-first).
Uma das vantagens do code-first (ou como é também designado code-only), utilizando POCO (Plain Old CLR objects ), é que não ficamos “presos” ao Entity Framework, pois todas as classes geradas automaticamente herdam da classe EntityObject. Além disso, utilizamos as classes que queremos, com muito menos código (um exemplo mesmo pequeno como este tem mais de 300 linhas de código), o que torna a manutenção da aplicação muito mais simples.
Para usar esta abordagem, na qual somos nós que desenhamos as classes que vão representar as entidades, podemos selecionar o nosso modelo conceitual (*.edmx) e na janela de propriedades, na opção “Code Generation Strategy”, que está definida para Default, selecionamos None. Isto fará com que o código gerado automaticamente seja apagado, possibilitando desta forma o desenvolvimento personalizado.
Para representar o modelo conceitual mostrando anteriormente, e tendo em conta que este é um exemplo muito simples (para efeitos de demonstração apenas), necessitamos apenas de três classes: Artigo, Autor e RevistaModelContainer.
As duas primeiras classes ( Artigo e Autor), vão representar as duas entidades e definem as propriedades da classe e a associação entre ambas (usando uma ICollection). Podemos ter mais propriedades e mais métodos nas classes, mas, para que isto funcione, temos de ter pelo menos as que estão definidas no modelo.
IMPORTANTE: A declaração de variáveis em Visual Basic não é, como sabem, case sensitive. No entanto, na declaração das propriedades das entidades (classes) é obrigatório que se declarem de acordo com o modelo (*.edmx), ou seja, há distinção entre maiúsculas e minúsculas.
A terceira classe é onde se define o nosso Container, que herda do ObjectContext, ou seja, é onde criamos a ligação entre o Entity Framework e as nossas classes anteriores. O ObjectSet é novo na versão 4.0 do Entity Framework e permite-nos trabalhar os dados como coleções, permitindo também executar queries.
Como é possível ver neste código, habilitamos a opção LazyLoadingEnable do ObjectContext, colocando-a a True. O Lazy Loading permite que as entidades relacionadas sejam automaticamente carregadas da fonte de dados quando acedemos às propriedades de navegação (neste caso, Autores e Artigos).
E é tudo! Com poucas linhas de código criamos as nossas classes, que definem as nossas entidades, e criamos o nosso Container que permite interligar as classes com o Entity Framework.
Mas este é apenas um exemplo bastante simples e, caso usássemos um modelo complexo, com inúmeras entidades e associações, era muito trabalhoso criar todas estas classes POCO.
Por isso o Entity Framework permite a utilização/criação de templates que geram o código por nós. São designados por T4 (Text Template Transformation Toolkit) Text Templates e são arquivos de texto com uma extensão *.tt . Existe um template para a criação de classes POCO. Não está disponível nos templates do Visual Studio 201 0, mas se abrirmos o modelo conceptual e selecionarmos “Add Code Generation Item”, podemos pesquisar no Online Templates e instalar.
Após a rápida instalação, podemos então selecionar ADO.NET POCO Entity Generator.
Isto irá adicionar dois arquivos *.tt ao projecto: POCOModel.tt e POCOModel.Context.tt. O POCOModel tem as classes que representam as entidades e o POCOModel.Context tem as classe de contexto.
NOTA: Ao adicionarmos os templates ao projeto, todo o código de Entity Framework será apagado. Desta forma, e muito rapidamente, criamos as nossas classes POCO usando estes templates.
Como foi possível ver ao longo deste artigo, existem diferentes abordagens para a utilização do Entity Framework 4.0, permitindo criar um modelo relacional de uma base de dados, criar um modelo e com base neste criar a base de dados ou criando as nossas classes (entidades) usando POCO, ficando desta forma independentes e com a possibilidade de uma maior personalização de toda a lógica. A existência de templates permite simplificar o processo de criação de classes POCO e inclusive criar os nossos próprios templates.
No momento da criação deste artigo, já está disponível o Entity Framework 4.1 Release Candidate, que tem como principal novidade a DbContext API, que é uma abstracão simples do ObjectContex e que pode ser utilizada em qualquer abordagem (Database-First, Model-First e Code-First). Existem também algumas alterações na abordagem Code-First.
No momento da criação deste artigo, já está disponível o Entity Framework 4.1 Release Candidate, que tem como principal novidade a DbContext API, que é uma abstracão simples do ObjectContex e que pode ser utilizada em qualquer abordagem (Database-First, Model-First e Code-First). Existem também algumas alterações na abordagem Code-First.
Algumas referências:
Fora de tópico Mostrar Código Esconder Código Mostrar EmoticonEsconder Emoticon