Archive for the ‘Entity Framework’ Category.

Entity Framework 6–Trabalhando com os Nightly Builds

Olá pessoal,

Voltando agora a escrever mais sobre o Entity Framework, estamos aguardando a nova versão 6 (ainda sem data definitiva para ser lançado) que trará melhorias muito significativas e vamos explorar algumas delas nos próximos artigos.

Antes de qualquer coisa é importante saber que o Entity Framework 6 ainda está em versão Alfa (isto mesmo ALFA), sendo assim não é recompendado utilizar em projetos que já estejam em produção, o que não nos impede de já ir testando algumas coisas bem legais.

A primeira coisa é como instalar o EF 6 em um projeto. Normalmente você usar o Nuget Package Console para adicionar o EF a um projeto seu, com o seguinte comando: (abra antes o Tools/Library Package Manager/Package Manager Console)

PM> InstallPackage EntityFramework

Mas irá instalar o EF 5 que é a última versão de produção, lançada juntamente com o Visual Studio 2012 e o .Net 4.5. Mas se você quer instalar o EF 6 em um projeto, terá que utilizar o seguinte comando:

PM> InstallPackage EntityFramework –Pre

Isto irá instalar a última versão publicada do EF 6, que atualmente é a Alfa 1. Legal, isto permite que você trabalhe com o EF 6 e explore algumas funcionalidades bem interessantes, mas não queremos isto, queremos as coisas legais ainda não publicadas.

Acessando os Builds Noturnos

O EF 6, como todos já devem saber, é Open Source e todo o seu código fonte, eu realmente disse todo o código fonte, pode ser baixado no endereço http://entityframework.codeplex.com. Eu recomendo que você baixe o código e dê uma olhada em como o projeto está estruturado, como são os testes unitários. O código fonte do EF é, sem dúvida alguma, uma excelente fonte de estudos.

Apesar do EF 6 ser totalmente open source, apenas a Microsoft libera as versões oficiais e também as chamadas Nightly Builds ou Build Noturnos, que nada mais são do que uma versão diária do que está sendo desenvolvido pela Microsoft e pela comunidade que está colaborando no projeto. Se você é, assim como eu, uma pessoa que gosta muito das novidades e fica ansioso por testá-las, estes builds noturnos nos dão isto.

Para ter acesso aos Nightly Builds você precisa configurar o Visual Studio para acessar o endereço onde eles são publicados diariamente. Vamos fazer isto acessando a configuração do NuGet em Tools/Library Package Manager/Package Manager Settings e depois em Package Source:

SNAGHTMLc0f2ab2

Clique no botão “+” e depois preencha os campos:

Name: Nightly Builds
Source: http://www.myget.org/F/aspnetwebstacknightly/

Salve clicando no OK. Agora que já configuramos, vamos criar um projeto do tipo Console para poder adicionar a última versão nortuna publicada. Para isto crie o projeto do tipo Console, escolhendo o .Net 4.5 pois alguns novos recursos só irão funcionar nesta versão do .Net.

Com o projeto criado, clique com o botão direito do mouse no nome da sua solução e depois escolha Manage Nuget Packages e você verá a imagem abaixo:

SNAGHTMLc1440a3

Veja que já temos os Nightly Builds na nossa janela, mas antes ainda precisamos indicar que queremos os “Pre Releases”, que são as versões ainda não oficiais. Você pode fazer isto clicando na opção “Stable Only” e mudando para “Include Prerelease”.

Feito isto vamos clicar em “Nightly Builds” e na janela de busca vamos digitar “Entity” e veja que você verá a última versão publicada, no meu caso do dia 18/08/2013:

SNAGHTMLc172099

Agora é só clicar em “Install” para instalar a última versão.

Uma lista da novas funciondalidades pode ser obtidas no endereço: http://entityframework.codeplex.com/wikipage?title=specs

Nos próximos post iremos explorar mais detallhadamente algumas destas novas funcionalidades!

Abraços e até a próxima,
Carlos dos Santos.

Visual Studio Summit 2013

Pessoal,

No último sábado, dia 25/05/2013, aconteceu na sede da Microsoft em SP o Visual Studio Summit 2013. Neste ano tive o prazer de realizar duas palestras: Entity Framework 6 e Debug de Aplicações Windows 8 no Device. As duas palestras também foram repetidas, o que tornou o meu dia um pouco mais intenso!

Gostaria de agradecer a excelente audiência que tive nas palestras, onde tive salas praticamente lotadas!

Aqui estão as fotos do eventos que publiquei no Facebook. Para quem esteve na palestra de Entity Framework, eu também disponibilizei o código fonte dos exemplos no meu Skydrive.

Vídeo da Palestra de EntityFramework 6

 

Vídeo da Palestra de Debug de Aplicações Windows 8 no Device

 

Abraços e até a próxima,
Carlos dos Santos.

Entity Framework–Open Source

Pessoal,

A Microsoft anunciou hoje que o Entity Framework terá seu código fonte Open Source e ela vai contar com a ajuda da comunidade para poder melhorá-lo.

Mesmo sendo Open Source, a Microsoft irá continuar o desevolvimento do produto, e já fala inclusive no roadmap do Entity Framework 6.

Se você tem interesse em conhecer o código fonte, e principalmente, contribuir, acesse o portal do projeto no CodePlex no link: http://entityframework.codeplex.com/

Abraços e até a próxima.
Carlos dos Santos.

Entity Framework Code First–Migrations

Olá pessoal,

Uma das grandes funcionalidades do Entity Framework Code First é o processo de atualização automatica do banco de dados através do pacote chamado Migrations.

O Migrations permite que você, que já trabalha com o CodeFirst, gere atualizações gerenciáveis no seu banco de dados, ou se preferir, deixar que o próprio Migrations cuide de tudo de forma automatica, mantendo seu banco de dados sempre atualizado com suas classes.

Na prática temos duas maneiras de trabalhar com o Migrations:
1. Usar pontos de migração no banco de dados, onde podemos avançar, aplicando as últimas modificações, ou voltar na linha do tempo, em qualquer momento do banco de dados;
2. Usar o modo totalmente automático, onde você não precisa se preocupar em atualizar o banco, pois ao executar o seu programa, isto será feito de maneira automatica.

Mas qual dos dois modelos eu devo utilizar em minha aplicação ? E a resposta é: Depende!. Se você precisa de um controle rigoroso das modificações, se precisa gerar scripts que serão executados no seu ambiente de produção, o melhor é usar o modo mais manual. Mas se o que lhe interessa é manter o banco sempre atualizado, sem se preocupar em rodar scripts, então use o modo automatico.

Neste artigo iremos abordar os dois métodos de utilização do Migrations e após entender cada um você poderá optar pelo que melhor se adequa ao seu processo.

Criando o projeto de exemplo

Antes de começar, vamos criar nosso projeto de exemplo. Eu estou usando o Visual Studo 2012, mas você pode também usar o Visual Studio 2010.

Vamos iniciar criando um projeto do tipo console, com o .Net Framework 4:
image

Logo após criar o projeto, vamos adicionar o Entity Framework CodeFirst usando o NuGet. Para isto abra o gerenciador do NuGet em Tools/Library Package Manager/Packager Manager Console e digite:
image

Após isto teremos o EF CodeFirst instalado em nosso projeto. Vamos agora criar um Contexto e uma classe para podermos trabalhar com o Migrations.

Esta será a nossa classe de Contexto:

public class Contexto : DbContext
    {
        public DbSet<Cliente> Cliente { get; set; }
    }

E esta será a nossa classe de Clientes:

public class Cliente
    {
        public int ID { get; set; }
        public string Nome { get; set; }
    }

Vamos também adicionar um arquivo app.config para identificarmos nosso servidor SQL e o nome do banco de dados:

<?xml version="1.0" encoding="utf-8"?>
<configuration>
  <connectionStrings>
    <add name="Contexto" providerName="System.Data.SqlClient" connectionString="data source=(local); initial catalog=ExemploMigrations; integrated security=true;"/>       
  </connectionStrings>
</configuration>

Agora que já temos nossas classes e o arquivo de configuração, vamos adicionar o Migrations.

Migrations – Gerenciando cada atualização no banco de dados

Vamos inicialmente adicionar o Migrations ao nosso projeto. Independente do método: manual ou automático, precisamos adicioná-lo ao nosso projeto. Faremos isto usando novamente a janela do Nuget através do comando Enable-Migrations:
image

Após este comando, uma nova classe será adicionada ao nosso projeto, o nome dela é Configurations:
image

Como vamos trabalhar com o processo manual, vamos deixar esta classe como está e vamos iniciar com os comandos do Migrations, que devem ser executados na janela do NuGet:

Agora, para todas as alterações que fizermos nas classes executaremos basicamente dois comandos:
Add-Migrations
Update-DataBase

Add-Migrations “nome_migrations” – cria um alteração no banco de dados, onde o “nome_migrations” é o nome que você irá dar para a atualização;
Update-DataBase – aplica as alterações no banco de dados;
Update-DataBase – script – gera um script com os comandos SQL para serem executados no banco de dados.

Para nosso exemplo, iremos executar:
Add-Migrations “CriacaoBanco”
Update-DataBase

Veja que ao executar o Add-Migrations, um novo arquivo foi adicionado ao projeto, contendo os comandos Migrations para o banco de dados:
image

public partial class CriacaoBanco : DbMigration
    {
        public override void Up()
        {
            CreateTable(
                "Clientes",
                c => new
                    {
                        ID = c.Int(nullable: false, identity: true),
                        Nome = c.String(),
                    })
                .PrimaryKey(t => t.ID);
            
        }
        
        public override void Down()
        {
            DropTable("Clientes");
        }
    }

Como nosso banco de dados ainda não existia, ele foi criado após o comando Update-DataBase:
image

Para que nossos exemplo fiquem mais interessantes, vou adicionar alguns registros no banco de dados usando o código abaixo, mas se você preferir, insira os dados diretamente no SQL:

static void Main(string[] args)
        {
            var db = new Contexto();
            db.Cliente.Add(new Cliente() { Nome = "Carlos dos Santos" });
            db.Cliente.Add(new Cliente() { Nome = "Jose da Silva" });
            db.Cliente.Add(new Cliente() { Nome = "Antonio das Couves" });
            db.SaveChanges();
        }

Agora vamos começar a modificar a nossa classe e ver como realmente o migrations pode nos ajudar. Inicialmente vamos adicionar um campo chamado Ativo na classe Cliente, e logo após vamos criar um novo Migration para enviar isto ao banco de dados:

Classe Cliente com o novo campo:

public class Cliente
    {
        public int ID { get; set; }
        public string Nome { get; set; }
        public bool Ativo { get; set; }
    }

Agora ao executar o comando Add-Migrations “Cliente_Ativo” teremos mais um arquivo do Migrations:

public partial class Cliente_Ativo : DbMigration
    {
        public override void Up()
        {
            AddColumn("Clientes", "Ativo", c => c.Boolean(nullable: false));
        }
        
        public override void Down()
        {
            DropColumn("Clientes", "Ativo");
        }
    }

Mas antes de enviar isto para o banco, vamos imaginar que você queira setar um valor para o campo Ativo, por exemplo, todos os campos Ativos deverão estar true. Você pode fazer isto através do comando Sql() dentro do arquivo do migrations, veja:

public partial class Cliente_Ativo : DbMigration
    {
        public override void Up()
        {
            AddColumn("Clientes", "Ativo", c => c.Boolean(nullable: false));
            Sql("update clientes set ativo = 1");
        }
        
        public override void Down()
        {
            DropColumn("Clientes", "Ativo");
        }
    }

Obviamente você poderia ter definido isto como um valor default par o banco, mass o intuito aqui é lhe mostrar como é possível enviar comandos durante o processo do Migrations.

Agora vamos enviar o comando para o banco, mas de uma maneira um pouco diferente, vamos gerar um script SQL. Para isto execute o comando da seguinte maneira:

Update-DataBase –script

E o resultado será um arquivo de script SQL:

ALTER TABLE [Clientes] ADD [Ativo] [bit] NOT NULL DEFAULT 0
update clientes set ativo = 1
INSERT INTO [__MigrationHistory] ([MigrationId], [CreatedOn], [Model], [ProductVersion]) VALUES ('201207160033131_Cliente_Ativo', '2012-07-16T00:38:19.710Z', 0x1F8B0800000000000400CD56C96EDB3010BD17E83F083CB587988E0B0449202748ECB8085A3B4194E64E4B6387281755A40CFBDB7AE827F5173AD46E79C97AE84D2267797C7C33C3BFBFFFF8E74B29BC0524866BD527879D2EF140853AE26ADE27A99D1D1C93F3B38F1FFCAB482EBD87D2AEE7ECD053993E79B4363EA5D4848F2099E9481E26DAE899ED845A521669DAEB768FE9619702862018CBF3FCBB54592E21FBC1DF815621C4366562AC2310A658C79D208BEA4D980413B310FAE46A0932167ACCE709B308C610EF427086400210B317A2EA9E3854A4CA8719AF10995DDDAF62C8B2F6C9407050169A4668F60D566B0BB8749BE81812BBBA8359E17A3D241E5DF7A36DC7CAADE1E3B2E397B25F7AC49BA442B0A9C08519130688171F9D065627F01514200710DD326B21C16BB98E20435FB0701A1F3D8F8813DAED392228534ADB8CD60DE02D98132DA1041AD804E542BC115F42F41DD4DC3E5660C76C59AEE027F17E288EEA42279BA4D03C5CFEBF3FE985E50B5D66BDD45A00535B086A06F1697DA19BD78CC2B38C238DE55DE33F2CAD6E5D766E1C806D49C2AB63E7F2EB543BDB3054D96A7DD35CE06521D01D95E08F591C23C78DCA2856BC202F8BC141F072EDCB3C060DCD9612A8D0569950746C0EAD5D475A04239E183B64964D99BB814124B798EDE7B64CB3A7EAD6CAB3B477DFB9CF466BE8EC8852D337C2134934C90E0715969DF933DF206482255BEA76A0452AD5AEDADFE79D9753D33F5F797E84A2369A218AA5CD183E6D1DBFCD32DDA0B9D5C5DAB7B64FED6D932A7BA5FA96BAFD42694F0F830DE9E526C44372163C72B20B56C682EC38834EF04BE4F75A1B8C99E23330F65EFF0437D8B0325E3F50AA3E6A4C24FED3A9C2DDE99F9C1F7B7BEAFE69A0162C091F59F249B2E5E73775F829B7EFDCDDDB8DEACD6D3ED75B9F4453873AC7596C9A570F814DF9FBB4F962F28760F8BC0EE1DE4F0A42D7F2EAA0A5CDB59AE992643C5A135169D2BA8331581621431789E533165ADC0EC1986CC43F3091BA4E2BA7105DAB9BD4C6A9BD3006E454AC9AE7F5E9FEFCD9A45BC7ECDFC459D37E8F23204C8E47801B7599721155B8475B24B42384134B5121880A9F38186EBEAA224DB47A66A082BE21C4A05C7DDDBB2185C1CC8D0AD80276637B9AC375C6FC216738F96493C17CA5401230CCDC4881099A1E753EF7E0A7EEC57FF60FBDB90F33230C0000, '4.3.1')

Basta executar este arquivo dentro do SQL que o campo será criado e atualizado, ou se preferir, execute novamente o Update-DataBase que isto será feito automaticamente.
Este recurso do script pode ser util se você precisar atualizar também um ambiente e produção da sua aplicação.
image

Obs: A tabela __MigrationHistory é usada pelo Migrations para gerenciar o histórico das versões dentro do banco de dados.

Voltando o banco de dados em um determinado ponto:

Um recurso bem interessante do Migrations é que você pode voltar o seu banco de dados a qualquer ponto em que tenha executado um Add-Migrations. Imagine então que nós criamos o campo ativo no banco e agora você queira voltar ao ponto onde este campo ainda não existia, para isto vamos executar o seguinte comando do Migrations:

Update-DataBase –target “CriacaoBanco”

Isto volta nosso banco de dados a este ponto, que nosso caso foi a criação do banco, mas poderia ser qualquer outro ponto. Lembrando que este comando afeta apenas o banco de dados e não a nossa classe.

Agora vamos ver como é executar o Migrations de forma totalmente automatica.

Migrations – Executando as atualizações automaticamente

Agora que você já sabe como manter seu banco de dados atualizados, gerando versões das atualizações, vamos imaginar que você não precisa manter este histórico, mas simplesmente manter o banco atualizado.

Para este exemplo, vamos criar um projeto com os mesmos dados do exemplo anterior, ou seja: crie um projeto do tipo console:
image

Adicione o EF CodeFirst através do console do NuGet e depois adicione o contexto, a classe cliente e o arquivo app.config, mas neste arquivo iremos modificar o nome do bando de dados para ExemploMigrationsAutomatico:

public class Contexto : DbContext
    {
        public DbSet<Cliente> Cliente { get; set; }
    }

public class Cliente
    {
        public int ID { get; set; }
        public string Nome { get; set; }
    }
<?xml version="1.0" encoding="utf-8"?>
<configuration>
  <connectionStrings>
    <add name="Contexto" providerName="System.Data.SqlClient" connectionString="data source=(local); initial catalog=ExemploMigrationsAutomatico; integrated security=true;"/>
  </connectionStrings>
</configuration>

Feito isto vamos adicionar o migrations, da mesma forma que antes, mas agora modificando os parâmetros necessários para que tudo fique automático, então abra o console do NuGet e execute o comando Enable-Migrations:
image

Agora que começam as diferenças. No exemplo anterior não modificamos nada na classe configurations, mas neste caso iremos fazer alguns ajustes:
image

Primeiro vamos mudar a classe para “public class”, pois precisaremos refenciá-lá posteriormente. Depois vamos ativar a propriedade da migração automatica e por fim vamos marcar a opção que dados podem ser perdidos durante a migração. Esta última opção fica a seu critério, pois se você não habilitar a opção e o Migrations não conseguir atualizar o banco de dados. você receberá um erro.

E agora vamos modificar o construtor do contexto para ele chamar o DatabaseInitializer, que é quem faz todo o processo acontecer:

public class Contexto : DbContext
    {
        public DbSet<Cliente> Cliente { get; set; }

        public Contexto()
        {
            Database.SetInitializer(new MigrateDatabaseToLatestVersion<Contexto, Configuration>());
        }
    }

O que fizemos foi adicionar a chamada do DatabaseSetInitializer() com a opção MigrateDatabaseToLastVersion, o que faz com que nosso banco de dados seja sempre atualizado de acordo com as nossas classes.

Agora é só executar o exemplo abaixo para criarmos o banco de dados:

static void Main(string[] args)
        {
            var db = new Contexto();
            db.Cliente.Add(new Cliente() { Nome = "Carlos dos Santos" });
            db.Cliente.Add(new Cliente() { Nome = "Jose da Silva" });
            db.Cliente.Add(new Cliente() { Nome = "Antonio das Couves" });
            db.SaveChanges();
        }

Agora vamos modificar a classe cliente e simplesmente executar o programa novamente:

    public class Cliente
    {
        public int ID { get; set; }
        public string Nome { get; set; }
        public string CPF { get; set; }
        public decimal Limite { get; set; }
    }

Após executar o programa e fazer uma consulta no SQL:
image

Conclusão:

O recurso de Migrations sem dúvida é algo realmente fantástico no Entity Framework CodeFirst e certament ajuda na produtividade do nosso dia a dia. Escolha o que melhor lhe atender e começe a usar agora mesmo.

Abraços e até a próxima.
Carlos dos Santos.

Academia de Entity Framework 4

Pessoal,

Está no ar o Microsoft Virtual Academy (MVA) do Entity Framework 4. É um treinamento básico sobre o EF, com seus conceitos fundamentais e vários exemplos de códigos.

O MVA é composto de vídeos explicativos e também de artigos e de uma prova. Para quem está começando com EF, é uma excelente fonte de aprendizado.

Esta academia foi grava por mim, Renato Haddad e pelo Fernando Henrique.

O link é https://www.microsoftvirtualacademy.com/tracks/fundamentos-do-entity-framework-4

Abraços,
Carlos dos Santos

Entity Framework 4.3 lançado!

Pessoal,

A Microsoft acaba de lancar a versão 4.3 do Entity Framework CodeFirst, agora com todas as novidades que vinham sendo trabalhadas nos betas, consolidadas nesta versão.

Um dos pontos mais trabalhados foi o Migrations, que permite que você atualize o banco de dados, seja de desenvolvimento ou produção, simplesmente através das mudanças em suas classes POCO.

Muitas novidades ainda estão por vir na versão que deverá sair logo após o lançamento do novo Visual Studio, pois muitas das mudanças anunciadas para o Entity Framework, como por exempo suporte a enums, necessita de mudanças também no .Net Framework.

Confira as novidades nos links:
http://blogs.msdn.com/b/adonet/archive/2012/02/09/ef-4-3-released.aspx
http://blogs.msdn.com/b/adonet/archive/2012/02/09/ef-4-3-code-based-migrations-walkthrough.aspx
http://blogs.msdn.com/b/adonet/archive/2012/02/09/ef-4-3-automatic-migrations-walkthrough.aspx

Abraços e até a próxima,
Carlos dos Santos.

EntityFramework CodeFirst

No post anterior, eu falei em como trabalhar com Entity Framework usando o Designer, ou seja, um modelo de classes criado a partir de um arquivo EDMX. Este modelo funciona perfeitamente em diversos tipos de projetos, mas o grande incoveniente é ter um arquivo EDMX para cada tipo de banco de dados do seu projeto.

Então vamos agora usar uma abordagem diferente, mas nem tão diferente assim do artigo anterior. Nossa necessidade ainda é manter o isolamento do banco de dados e trabalhar somente com objetos. O CodeFirst, como o próprio nome sugere, nos leva a criar primeiramente as classes POCO e depois o banco de dados, mas é possível também pegar um banco de dados existente e gerar o CodeFirst.

O Entity Framework faz uma ponte entre as classes POCO e o banco de dados utilizando um container que chamamos de Contexto. O contexto é o responsável por mapear as nossas classes com o banco de dados e também por informar ao engine quem é o banco de dados, através da string de conexão, e isto é o que mais me agrada no Code First, você precisa trocar somente a string de conexão para mudar de banco. Nenhum tipo de alteração no código é necessária.

Instalando o Entity Framework Code First:

Antes de começarmos a escrever as classes, precisamos instalar o Entity Framework CodeFirst, que é basicamente composto pela EntityFramework.DLL. Faremos isto isando o NuGet, que é um instalador de pacotes para o Visual Studio. Se você ainda não o possui, vá até o Extension Manager do Visual Studio (Tools/Extension Manager) e instale:

SNAGHTMLa23ac4a_thumb1_thumb

Depois de instalado o NuGet, vá em Tools/Library Package Manager/Package Manager Console. Isto vai abrir o gerenciador do NuGet:

image_thumb1_thumb

Agora digite o comando: Install-Package EntityFramework dentro do console, isto irá instalara o EF CodeFirst e suas dependências:

Criando um projeto com o EntityFramework CodeFirst:

Vamos criar uma classe de contexto que chamaremos de Contexto.cs, esta classe irá herdar de DbContext e nela iremos mapear nossas tabelas:

   1: using System;

   2: using System.Collections.Generic;

   3: using System.Linq;

   4: using System.Text;

   5: using System.Data.Entity;

   6:  

   7: namespace EFCodeFirst

   8: {

   9:     public class Contexto : DbContext

  10:     {

  11:         public DbSet<Grupo> Grupo { get; set; }

  12:         public DbSet<Produto> Produto { get; set; }

  13:     }

  14: }

O segredo aqui é o DBSet<>, pois ele faz o mapeamento da nossa classe para o banco e vincula a um objeto, que utilizaremos para fazer as operações com o BD.

Veja o código da classe Grupo:

   1: using System;

   2: using System.Collections.Generic;

   3: using System.Linq;

   4: using System.Text;

   5: using System.ComponentModel.DataAnnotations;

   6:  

   7: namespace EFCodeFirst

   8: {

   9:     [Table("Grupo")]

  10:     public class Grupo

  11:     {

  12:         public int ID { get; set; }

  13:         [Required(ErrorMessage="Nome não pode ser branco.")]

  14:         public string Nome { get; set; }

  15:  

  16:         public virtual IQueryable<Produto> Produtos { get; set; }

  17:     }

  18: }

E da classe Produto:

   1: using System;

   2: using System.Collections.Generic;

   3: using System.Linq;

   4: using System.Text;

   5: using System.ComponentModel.DataAnnotations;

   6:  

   7: namespace EFCodeFirst

   8: {

   9:     [Table("Produto")]

  10:     public class Produto

  11:     {

  12:         public int ID { get; set; }

  13:         [Required(ErrorMessage="Nome não pode ser branco.")]

  14:         public string Descricao { get; set; }

  15:         public int GrupoID { get; set; }

  16:  

  17:         [ForeignKey("GrupoID")]

  18:         public virtual Grupo Grupo { get; set; }

  19:     }

  20: }

No CodeFirst podemos controlar todos os aspectos do mapeamento das classes com o banco de dados, desde o nome da tabela no banco, obrigatoriedade dos campos, tamanho, etc.

Na classe Grupo, eu determinei o nome da tabela no banco de dados (linha 9), ou seja, podemos ter um nome para a classes e outro para a tabela no banco de dados. Informei também que o nome não pode ser banco e vinculei uma mensagem, que pode ser usada em projetos MVC e WPF (linha 13). Finalmente criei o relacionamento entre Grupo e Produto (linha 16).

Na classe Produto, eu determinei também o nome da tabela no banco de dados, e o campo obrigatório. Fiz também o relacionamento com a tabela grupo através do campo GrupoID (linhas 15 e 17,18).

O EF identifica também automaticamente as chaves primárias das tabelas, desde que você as chame por ID ou nome_da_tabelaID, exemplo: GrupoID ou ProdutoID.

Um coisa muito legal que o EF CodeFirst faz para nós é criar o banco de dados, mas isto depende do provider do seu banco de dados, nem todos aceitam a criação do banco.

Vamos agora montar um exemplo para carregar dados no nosso banco:

   1: using System;

   2: using System.Collections.Generic;

   3: using System.Linq;

   4: using System.Text;

   5:  

   6: namespace EFCodeFirst

   7: {

   8:     class Program

   9:     {

  10:         static void Main(string[] args)

  11:         {

  12:             var db = new Contexto();

  13:  

  14:             db.Database.CreateIfNotExists();

  15:  

  16:             var g1 = new Grupo() { Nome = "Peças" };

  17:             var g2 = new Grupo() { Nome = "Serviços" };

  18:  

  19:             db.Grupo.Add(g1);

  20:             db.Grupo.Add(g2);

  21:  

  22:             var p1 = new Produto() { Descricao = "Pneu", Grupo = g1 };

  23:             var p2 = new Produto() { Descricao = "Roda", Grupo = g1 };

  24:             var p3 = new Produto() { Descricao = "Alinhamento", Grupo = g2 };

  25:             var p4 = new Produto() { Descricao = "Balanceamento", Grupo = g2 };

  26:  

  27:             db.Produto.Add(p1);

  28:             db.Produto.Add(p2);

  29:             db.Produto.Add(p3);

  30:             db.Produto.Add(p4);

  31:  

  32:             db.SaveChanges();

  33:  

  34:             var dados = from p in db.Produto

  35:                         select p;

  36:  

  37:             foreach (var linha in dados)

  38:             {

  39:                 Console.WriteLine("{0,-30} - {1}", linha.Grupo.Nome, linha.Descricao);

  40:             }

  41:  

  42:         }

  43:     }

  44: }

O código acima cria o nosso banco de dados no SQL, caso ele não exista (linha 14). Após isto eu inseri os dados em Grupo e Produto, mas percebam que eu simplesmente vinculei os objetos, sem me preocupar com as chaves primárias ou estrangeiras, pois o EF resolve isto para nós desde que seu mapeamento esteja correto.

Assim ao final do código temos o banco de dados criado e os dados inseridos. Veja como ficou o banco de dados no Management Studio:

image_thumb3_thumb1

Veja que o nome do banco de dados é o nome da aplicação mais o nome do Contexto, mas podemos resolver isto adicionando um arquivo App.Config e informando os dados do banco, então vamos adicionar um arquivo de configuração ao nosso exemplo e colocar a seguinte linha:

   1: <?xml version="1.0" encoding="utf-8" ?>

   2: <configuration>

   3:   <connectionStrings>

   4:     <add name ="Contexto" providerName="System.Data.SqlClient" connectionString="data source=(local); initial catalog=ExemploEF; user id=teste; password=teste;"/>

   5:   </connectionStrings>

   6: </configuration>

O nome da string de conexão é o mesmo nome da nossa classe de Contexto. O providerName indica que usamos SQL Server e a string de conexão é padrão de ADO.Net, informando Servidor/Banco de Dados/Usuário. Eu já fiz outro post falando só sobre Gerenciamento de Strings de Conexão.

Executando nosso código novamente o banco chamado EFExemplo será criado e preenchido com os dados.

Visualizando o modelo do CodeFirst:

Mas e se você quiser ver como está ficando seu modelo se você está usando somente código ? Para isto existe o Entity Framework PowerTools que permite visualizar o modelo a partir das classes e também gerar um script para o banco de dados. Vejamos como ver o modelo visual do nosso exempo.

Após instalar o PowerTools, clique com o botão direito do mouse sobre a classe Contexto.cs no seu projeto, irá aparecer um menu de contexto EntityFramework, com várias opções:

image_thumb5_thumb1

A primeira opção é justamente a que mostra o modelo gráfico, vamos vê-lo então:

image_thumb3[1]

Já tenho um banco de dados e quero usar o CodeFirst:

Se você já tiver um banco de dados, o EF PowerTools permite que você faça engenharia reversa e gere o contexto e as classes, para isto clique com o botão direito do mouse em sua Solution no Visual Studio e escolhar Entity Framework no menu:

image_thumb9_thumb1

Esta opção gera todas as classes e relacionamentos do seu modelo, basta informar qual o banco de dados e o servidor na janela abaixo:

SNAGHTMLa560840_thumb1_thumb1

Não se esquece de adicionar o EntityFramework CodeFirst com o NuGet antes de fazer a engenharia reversa.

Quando usar Designer ou CodeFirst:

Esta é um pergunta bem complicada, eu diria que se você usa somente um banco de dados e precisa trabalhar com Stored Procedures é melhor usar o Designer, principalmenet porquê o CodeFirst ainda não suporta procedures nativamente.

Se você quer criar uma aplicação multibanco, de maneira mais rápida e simples através de classes POCO, então o CodeFirst é sua escolha.

Muito importante saber também que o Entity Framework Designer e o CodeFirst são independentes e podem não compartilhar alguns recursos.

Espero que o artigo seja útil para vocês e se assim desejarem façam seus comentários ou sugestões.

Até a próxima,
Carlos dos Santos.

Trabalhando com Entity Framework Designer

Olá pessoal,

Hoje em um desenvolvimento de projeto é muito comum  o programador ter que saber vários comando de bancos de dados (Insert, Delete, Update, Select) para poder desenvolver, além de saber sobre a linguagem de progração. O EntityFramework vem para ajudar nesta tarefa, criando uma correspondência entre as tabelas do banco de dados, o que chamamos de ORM, ou mapeamento Objeto-Relacional.

Existem, basicamente, duas maneiras de se trabalhar com o Entity Framework, usando o Entity Designer ou o Entity Framework Code First. A diferença é simples, no Designer você precisa criar um diagrama do banco de dados visualmente, usando um arquivo EDMX, que deve ser específico para cada banco de dados da sua aplicação, ou seja, para cada banco de dados é necessário usar um arquivo EDMX. Neste artigo vamos vamos criar um modelo visual e analisar seus aspectos.

Mapeando o Banco de dados com o Entity Designer:

Abra o Visual Studio 2010 e crie um projeto no .Net Framework 4 do tipo Console Application, depois vá em adcionar novo item. Você verá a janela abaixo, escolha ADO.Net Entity Data Model:

SNAGHTML9dffcc9

Podemos ainda escolher se iremos nosso modelo a partir de um banco de dados pronto ou em branco:

image

Vamos gerar nosso exemplo a partir do banco de dados NorthWind, escolhendo a opção “Generate from database”. Na tela seguinte crie a conexão para o banco de dados e depois escolha quais tabelas, views ou stored procedures você quer mapear:

SNAGHTML9e3d339

No nosso exemplo ou escolher todas as tabelas, views e stored procedures. Feito isto teremos o modelo visual pronto:

image

Este processo gerou um modelo EDMX, que contém basicamente três partes:

1. Storage Model Content: que contém as informações do banco de dados, como tabelas, tipos dos dados, etc;
2. Conceptual Model Content: contém a definição do modelo, o que você pode ver no diagrama, como as classes, tipos complexos, associações, etc.
3. Mapping Content: faz a ligação entre o Storage e o modelo Conceitual.

O código fonte das classes também faz parte do modelo,dentro do arquivo de Designer:

image

Este arquivo contém o código fonte de todas as classes de nosso modelo. Mas então se eu criar um modelo novo as classes serão geradas novamente ? A resposta é SIM.

Opa, mas então temos um problema, teremos classes duplicadas e como vamos resolver isto ? Com classes POCO, que podem ser independentes do modelo. Para isto faremos algumas pequenas modificações no nosso modelo.

Se você for utilizar somente um banco de dados não precisa trabalhar com classes POCO.

Trabalhando com POCO no Entity Designer:

A primeira coisa que precisamos fazer é desativar a geração de código pelo designer. Isto é simples, basta desligarmos a propriedade Code Generation Strategy do modelo, colocando em none:

image

Agora precisamos adicionar novamente as classes e para isto iremos utilizar um gerador automático de código, que iremos adicionar ao nosso projeto:

SNAGHTML9f0e092

Ao adicionarmos o ADO.Net POCO Entity Generator, dois novos arquivos irão aparecer em nosso projeto: Model1.Context.tt e Model1.tt. Para gerar as classes precisamos abrir cada um deles e colocar o nome do nosso arquivo EDMX, Veja o exemplo:

image

No nosso exemplo ficará assim: string inputFile = @”model1.edmx”. Faça o mesmo no arquivo Model1.tt. Depois de fazer isto salve o arquivo e o nosso projeto ficará assim:

image

Agora temos classes POCO, que são independentes do designer. Se você modificar o designer, assim que salvá-lo as classes serão atualizadas automaticamente.

Agora você pode adicionar um novo EDMX apontando para um outro banco de dados, por exemplo: MySQL ou Oracle, desde que tenham a mesma estrutura logicamente, e você usará as mesmas classes.

Usando o modelo para recuperar os dados:

Vamos agora criar um pequeno código para listar os Products e Categories do nosso modelo, usando LINQ:

   1: var db = new NorthwindEntities();

   2:  

   3:             var dados = from p in db.Products

   4:                         select p;

   5:  

   6:             foreach (var linha in dados)

   7:             {

   8:                 Console.WriteLine("{0,-35} - {1}", linha.ProductName, linha.Categories.CategoryName);

   9:             }


No próximo artigo iremos falar sobre o Entity Framework Code First.

Espero que tenham gostado.

Até a próxima.

Carlos dos Santos.

Entity Framework com Oracle

A Oracle acabou de lancar seu provider nativo para o Entity Framework, a versão ODAC  11.2. Agora você já pode acessar nativamente o Oracle com o EF, facilitando o desenvolvimento através do mapeamento objeto relacional.

Para baixar acesse os links abaixo:

Usando EF com Oracle: http://www.oracle.com/technetwork/issue-archive/2011/11-sep/o51odt-453447.html

Provider 32 bits: http://www.oracle.com/technetwork/topics/dotnet/utilsoft-086879.html

Provider 64 bits: http://www.oracle.com/technetwork/database/windows/downloads/index-090165.html

 

[]s,

Carlos dos Santos.

EF Code First-Acessando Stored Procedures

Olá,

Vou iniciar este post informando que o Entity Framework Code First não tem suporte nativo para Stored Procedures, ainda!!!

Mas se não é suportado nativamente, então como é possível acessá-las ? Através do método SqlQuery() do contexto, mas existe um inconveniente: o acesso fica vinculado ao banco de dados, ou seja, para cada banco de dados o acesso é feito de uma maneira, mesmo porquê cada banco tem uma maneira específica de chamar e tratar os parâmetros das stored procedures.

Em nosso exemplo vamos demonstrar como acessar uma stored procedure do banco de dados NorthWind. A procedure que vamos utilizar é a CustOrderHist, que recebe como parâmetro o código do cliente e retorna os produtos e quantidades compradas pelo cliente.

Vamos então criar nosso projeto console no Visual Studio 2010 e já adicionar as referências para o EF CodeFirst, caso você não tenha o EF CodeFirst instalado em seu computador, pode baixá-lo aqui.

image

Para pegar o retorno da stored procedure, vamos criar uma classe que conterá os campos retornados:

   1: public class ProdutosPorCliente

   2: {

   3:     public string ProductName { get; set; }

   4:     public int Total { get; set; }

   5: }

Para obter o conteúdo da classe, você precisa verificar o que a stored procedure retorna e neste caso ela retorna os nomes dos produtos e a quantidade comprada.

Antes de criar nosso contexto, vamos criar o arquivo de configuração para a string de conexão, veja este post sobre strings de conexão.

   1: <?xml version="1.0" encoding="utf-8" ?>

   2: <configuration>

   3:   <connectionStrings>

   4:     <add name="Contexto" providerName="System.Data.SqlClient" connectionString="Data Source=(local);Initial Catalog=Northwind;Persist Security Info=True;User ID=teste;Password=teste;Pooling=False;MultipleActiveResultSets=true;" />

   5:   </connectionStrings>

   6: </configuration>

Agora vamos criar o nosso contexto e incluir a chamada para a stored procedure:

   1: class Contexto : DbContext

   2: {

   3:     public IEnumerable<ProdutosPorCliente> RetornaProdutosPorCliente(string codigoCliente)

   4:     {

   5:         SqlParameter parClienteID = new SqlParameter("@CustomerID", SqlDbType.Text);

   6:         parClienteID.Value = codigoCliente;

   7:  

   8:         return Database.SqlQuery<ProdutosPorCliente>("exec CustOrderHist @CustomerID", parClienteID);

   9:     }

  10: }

Veja que nosso contexto não possui as classes de dados, mas elas foram omitidas somente por uma questão didática.

O inconveniente aqui, como falamos no início é que a chamada da stored procedure fica vinculada ao banco de dados. No exemplo usamos SqlParameter() para criar o parâmetro, pois nosso banco de dados é SQL Server. Caso o banco seja diferente a classe de parâmetro muda.

Vamos agora ao exemplo para realizar a chamada ao método:

   1: static void Main(string[] args)

   2:         {

   3:             Contexto ctx = new Contexto();

   4:  

   5:             var retProc = ctx.RetornaProdutosPorCliente("VINET");

   6:  

   7:             foreach (var l in retProc)

   8:             {

   9:                 Console.WriteLine("{0} - {1}", l.ProductName, l.Total);

  10:             }

  11:         }

Veja que é bem simples, pois o método retorna um IEnumerable que pode ser percorrido por um foreach().

Espero que o exemplo seja útil, mas gostaria de deixar claro que este é somente um meio alternativo para acessar stored procedures.

Até a próxima,

Carlos dos Santos.