Posts tagged ‘msdn;c#;ef codefirst’

Melhorando o tempo de carga do Entity Framework com NGEN

A partir do Entity Framework 6, todos os componentes do EF estão dentro da DLL EntityFramework.dll e não mais divididas entre vários componentes do .Net Framework. Sendo assim, a DLL do EF não está otimizada para o JIT (Just in Time) do computador onde está sendo rodado, assim como o .Net está.

Nós podemos melhorar isto executando o comando Ngen.exe, que pré-compila a DLL e elimina este processo durante a carga da DLL. Assim o tempo de carga fica menor e podemos ganhar alguns segundos na carga da nossa aplicação.

Para fazer isto, abra um prompt de comandos do Visual Studio Studio, ele fica dentro das opções de instalação do Visual Studio, com um nome parecido com este: “Developer Command Prompt for VS 20xx”. No meu caso estou usando o VS 2013, então o prompt está como “Developer Command Prompt for VS2013”.

Abra este prompt como administrador, vá até o diretório da sua aplicação e execute o comando NGen, como abaixo:

C:Meu Projeto>ngen install EntityFramework.dll

Após isto você verá uma tela parecida como esta:

image

Valeu pessoal e até a próxima,
Carlos dos Santos.

Entity Framework 6–Gerando Log dos comandos SQL

Olá,

O Entity Framework 6 RC já foi lançado! Agora é a hora de começar a trabalhar na migraçãoda versão 5 para a 6 e ver as novas funcionalidades. As especificações sobre as novas funcionalidades podem ser encontradas aqui.

Dentre as muitas novidades, que vamos explorar nos post seguintes, hoje vou destacar uma que acho bem interessante: o log dos comandos enviados ao banco de dados.

Um ORM (Object-Relational Mapping), ou simplesmente um Mapeamento Objeto-Relacional traduz comandos de uma linguagem de programação, no nosso caso C# e LINQ, para comandos de banco de dados. A eficiência do ORM está diretamente relacionada a como os comandos para o banco de dados são gerados, ou seja, pegar os comandos escritos em C# e convertê-los em comandos SQL.

Na versão 6 do Entity Framework foi introduzido um novo objeto que nos permite interceptar os comandos que estão sendo enviados para o banco de dados e assim podemos ver o que acontece “por baixo dos panos”. Isto também podem ser feito colocando uma ferramenta de profiler de banco de dados. No caso do Microsoft SQL Server esta ferramenta é o SQL Server Profiler, mas existem vários outros.

No caso do nosso exemplo, vamos executar um método para cada operação em LINQ que será executada no Entity Framework, e para iniciarmos o nosso exemplo, vamos criar um projeto do tipo Console Application usando o .Net 4.5 (o uso do .Net 4.5 é importante para suportar todas as funcionalidades do Entity Framework 6).

Criando um novo projeto do tipo Console Application:

SNAGHTML476eb602

Criado o nosso projeto, vamos adicionar o Entity Framework através da janela do  Nuget, que está em Tools/Library Packager Manager/Packager Manger Console e dentro dele iremos executar o comando abaixo:

PM> Install-Package EntityFramework –Pre

Veja que a opção “-Pre” é quem irá instalar o Entity Framework 6 RC, visto que ele ainda não foi liberado oficialmente e ainda é um release candidate.

Agora vamos criar um contexto bem simples com uma classe Cliente. Para isto adicione uma nova classe e chame-a de Contexto, como no exemplo abaixo:

   1: public class Contexto : DbContext

   2: {

   3:     public DbSet<Cliente> Cliente {get; set;}

   4:  

   5: }

Agora vamos adicionar a classe Cliente:

   1: public class Cliente

   2:     {

   3:         public int ID { get; set; }

   4:         public string Nome { get; set; }

   5:     }

E por fim vamos modificar o arquivo App.Config para direcionarmos o local e o nome do banco de dados a ser criado: (isto é somente um exemplo e o seu arquivo poderá ficar diferente)

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

   2: <configuration>

   3:   <connectionStrings>

   4:     <add name="Contexto" connectionString="data source=(local); initial catalog=EFLog; integrated security=true;" providerName="System.Data.SqlClient"/>

   5:   </connectionStrings>

   6: </configuration>

Agora vamos ao que interessa, ou seja, vamos adicionar o LOG do SQL. Para isto, no Program.cs vamos inserir os seguintes comandos:

   1: class Program

   2:     {

   3:         static void Main(string[] args)

   4:         {

   5:             var db = new Contexto();

   6:             db.Database.Log = GravaLog;

   7:  

   8:             var cli = new Cliente() { Nome = "Carlos" };

   9:             db.Cliente.Add(cli);

  10:             db.SaveChanges();

  11:  

  12:             var consulta = from c in db.Cliente

  13:                            select c;

  14:             foreach(var c in consulta)

  15:             {

  16:                 Console.WriteLine(c.Nome);

  17:             }

  18:         }

  19:  

  20:         public static void GravaLog(string sql)

  21:         {

  22:             Console.WriteLine("Comando SQL: "+sql);

  23:         }

  24:     }

O método GravaLog() é atrbuído a propriedade Log do DataBase do Contexto, sendo assim, todos os comandos enviados para o banco de dados são também enviados para este método e dentro dele simplesmente chamamos o método Console.WriteLine() para mostrar os comandos na tela.

Ao executar o programa, você verá algo como a imagem abaixo:

SNAGHTML47817c48

Esta é uma implementação bastante simples da implementação do Log de comandos disponível agora na versão 6, mas com certeza você poderá utilizar de uma maneira bem mais elaborada em seus projetos.

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

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.

EF CodeFirst–Gerenciando as Strings de Conexão

Olá,

Hoje vamos falar um pouco sobre o gerenciamento de string de conexões no Entity Framework Code First, uma maneira muito simples e rápida de criar um mapeamento objeto relacional em C# com o Visual Studio 2010.

Se você ainda não conhece o EF CodeFirst, veja este post e também o Blog do time de ADO.Net.

O que vou tratar neste post é como podemos armazenar as strings de conexão e os providers que permitem o acesso do EF ao nosso banco de dados. Por padrão, quando criamos um contexto para nosso EF, é necessário uma string de conexão e um Data Provider, que indica qual o banco de dados será utilizado, mas se criarmos um contexto simples, sem nenhuma string de conexão, como no exemplo abaixo, o que acontece ?

 1: using System;

 

 2: using System.Collections.Generic;

 

 3: using System.Linq;

 

 4: using System.Text;

 

 5: using System.Data.Entity;

 

 6:

 

 7: namespace EFExemplo

 

 8: {

 

 9:     public class ContextoExemplo : DbContext

 

 10:     {

 

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

 

 12:     }

 

 13: }

 

Como não expecificamos nenhum construtor, o EF tentará usar o servidor .SQLExpress e tentará criar o banco de dados ContextoExemplo e caso você não tenha este servidor SQL disponível, receberá um erro.

Vamos imaginar que você queira especificar uma string de conexão, neste caso temos várias maneiras de fazer isto e vamos explorar cada uma delas:

Opção 1: Informar a string de conexão no construtor do contexto:

 1: public class ContextoExemplo : DbContext

 

 2:     {

 

 3:         public DbSet<Cliente> Cliente { get; set; }

 

 4:

 

 5:         public ContextoExemplo(string conexao) : base(conexao)

 

 6:         {

 

 7:

 

 8:         }

 

 9:     }

 

Neste caso podemos usar de duas maneiras: você pode informar somente a string de conexão e neste caso poderá usar somente o SQL Server, que é o provider default para o EF. Isto pode ser feito na instância do contexto:

 1: static void Main(string[] args)

 

 2: {

 

 3:     ContextoExemplo ctx = new ContextoExemplo("data source=(local); initial catalog=EFExemplo; user id=teste; password=teste;");

 

 4:     ctx.Database.CreateIfNotExists();

 

 5: }

 

Neste caso será criado o banco de dados EFExemplo no servidor SQL local.

Opção 2: Informar o noem de uma string armazenada em um arquivo de configuração:

A segunda maneira é você manter a string fora do executável, de maneira que você possa modificá-la a qualquer momento, neste caso usaremos o arquivo de configuração da aplicação (app.config ou web.config):

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

 

 2: <configuration>

 

 3:   <connectionStrings>

 

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

 

 5:     <add name="EFExemplo-MySql" connectionString="Server=localhost;Database=efexemplo;Uid=teste;Pwd=teste;Port=3306;" providerName="MySql.Data.MySqlClient"/>

 

 6:   </connectionStrings>

 

 7: </configuration>

 

No arquivo de configuração podemos agora manter mais de uma string e também informar qual o banco de dados de cada conexão. Para usar a conexão, basta informá-la no construtor:

 1: ContextoExemplo ctx = new ContextoExemplo("EFExemplo");

 

ou

 1: ContextoExemplo ctx = new ContextoExemplo("EFExemplo-MySql");

 

 

Opção 2: Informar um DbConnection:

DBConnection é a classe que cria as conexões para o EF CodeFirst, neste caso você pode gerar a string de uma maneira mais dinâmica e ela não precisa estar armazenada em um arquivo app.config ou web.config, o que deixaria a string mais exposta. Este mecanismo é interessante quando você quer criptografar a string, veja:

 1: public class ContextoExemplo : DbContext

 

 2: {

 

 3:     public DbSet<Cliente> Cliente { get; set; }

 

 4:

 

 5:     public ContextoExemplo(string conexao) : base(conexao)

 

 6:     {

 

 7:

 

 8:     }

 

 9:

 

 10:     public ContextoExemplo(DbConnection conexao) : base(conexao,true)

 

 11:     {

 

 12:

 

 13:     }

 

 14: }

 

Veja que agora temos uma sobrecarga do construtor, onde informamos o DbConnection e vamos fazer isto na instância do contexto:

 1: static void Main(string[] args)

 

 2: {

 

 3:     DbProviderFactory prov = DbProviderFactories.GetFactory("System.Data.SqlClient");

 

 4:     DbConnection conexao = prov.CreateConnection();

 

 5:     conexao.ConnectionString = "data source=(local); initial catalog=EFExemplo; user id=teste; password=teste;";

 

 6:

 

 7:     ContextoExemplo ctx = new ContextoExemplo(conexao);

 

 8:     ctx.Database.CreateIfNotExists();

 

 9: }

 

Para criarmos a conexão, primeiro precisamos identificar o tipo do banco de dados, através do DbProviderFactory() e logo a seguir, informamos a string de conexão que é depois passada como parâmetro para o contrutor do contexto. Note que a string de conexão poderia vir de um arquivo criptografado ou mesmo de um serviço web, o que aumentaria a segurança da aplicação.

Bem pessoal, espero que este post possa lhes ser útil.

Até breve,

Carlos dos Santos.