Jan 07

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.

Jan 07

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.

Jan 04

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.

Aug 20

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.

Aug 08

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.

Aug 20

EFProfiler– Entity Framework Profiler

Se você está trabalhando com EF4, provavelmente já se perguntou se os comandos SQL gerados estão realmente otimizados, ou talvez quando você tem algum problema de performance. Para responder a isto existem várias ferramentas de análise, ou profilers, e um destes é o EFProfiler.

A ferramenta é bastante simples, você baixa um executável do site www.efprof.com e segue as instruções contidas no arquivo “How to use.txt”.

Para o profiler funciona, você precisa adicionar a referência de um DLL do Profiler ao seu projeto:

image

Depois, no arquivo principal do projeto, você executa o inicializador do profiler:

   1: static void Main(string[] args)

   2: {

   3:     // Profiler

   4:     HibernatingRhinos.Profiler.Appender.EntityFramework.EntityFrameworkProfiler.Initialize();

   5:  

   6:     TesteEntities dc = new TesteEntities();

   7:  

   8:     var dados = from c in dc.Cliente

   9:                 select c;

  10:     foreach (var linha in dados)

  11:     {

  12:         Console.WriteLine(linha.Nome);

  13:     }

  14: }

No exemplo acima, temos uma simples consulta ao banco de dados.

Agora abra o profiler e execute sua aplicação, os resultados irão aparecer na tela:

image

É isto aí pessoal, bom profiler para vocês!

[]s,

Carlos dos Santos.

Jul 19

Consultas Genéricas com Linq

No conceito de orientação a objeto, sempre temos em mente criar códigos que possam ser reutilizados dentro da aplicação ou mesmo em aplicações diferentes, e neste contexto eu tenho sido questionado sobre como é possível usar Linq, que é totalmente orientado a objeto e fortemente tipado, e ainda sim criar códigos reusáveis.

Aproveitando esta situação, vou mostrar como é possível criar um método de consulta usando Linq, que serve para consultar praticamente qualquer entidade (tabela) do seu modelo, ou seja, iremos criar uma consulta totalmente genérica, e um dos possíveis lugares que você pode utilizar este tipo de método, é em uma rotina de consulta que você chama em todo o seu sistema, por exemplo.

Para o nosso exemplo, vamos criar um projeto console bem simples, lembrando que usaremos o Visual Studio 2010 com o Entity Framework 4:

image

Agora vamos adicionar o modelo do Entity Framework, para este exemplo usaremos o banco de dados Northwind, caso você não o tenha, baixe aqui. Para adicionar o modelo, clique com o botão direito do mouse sobre o seu projeto e vá em Add/New Item, ou CTRL + SHIFT + A e selecione Data e depois ADO.Net Entity Data Model. Escolha Generate from database e crie a conexão com o seu banco de dados Northwind. Selecione algumas tabelas, por exemplo: Categories, Products, Customers:

image

Criado o arquivo EDMX, vamos para o método de Consulta:

   1: static ObjectQuery<DbDataRecord> Consulta(string query, ObjectContext ctx)

   2: {

   3:     return new ObjectQuery<DbDataRecord>(query, ctx);

   4: }

Observação: adicione os seguintes namespaces:

using System.Data.Objects;

using System.Data.Common;

Parece que ficou complicado, mas é muito simples. Estamos retornando um objeto genérico do tipo DbDataRecord, e dentro do método, estamos retornando um novo ObjectQuery, que nos permite criar consultas dinamicamente. Vejamos um exemplo de chamada do método:

   1: static void Main(string[] args)

   2: {

   3:     NorthwindEntities ctx = new NorthwindEntities();

   4:  

   5:     var dados = Consulta("select c.ProductName,c.UnitPrice from Products as c" , ctx);

   6:  

   7:     foreach (DbDataRecord linha in dados)

   8:     {

   9:         Console.WriteLine(linha["ProductName"] + " - " + linha["UnitPrice"]);

  10:     }

  11: }

Primeiro criamos o contexto para o banco de dados Northwind, depois chamamos o método Consulta passando a nossa query e o contexto. Veja que a query se parece muito com uma consulta SQL, e neste caso estamos trazendo o ProductName e o UnitPrice da tabela Products.

Depois executamos um foreach() para mostrar os dados, usando o DbDataRecord para acessar os campos da consulta. Vejamos outro exemplo, agora trazendo dados também da tabela Categories:

   1: var dados = Consulta("select c.ProductName,c.UnitPrice,c.Categories.CategoryName from Products as c" , ctx);

   2:  

   3:             foreach (DbDataRecord linha in dados)

   4:             {

   5:                 Console.WriteLine(linha["ProductName"] + " - " + linha["UnitPrice"]+" - "+linha["CategoryName"]);

   6:             }


E para finalizar um exemplo com consulta condicional:

   1: var dados = Consulta("select c.ProductName,c.UnitPrice,c.Categories.CategoryName from Products as c where c.UnitPrice < 10" , ctx);

   2:  

   3:             foreach (DbDataRecord linha in dados)

   4:             {

   5:                 Console.WriteLine(linha["ProductName"] + " - " + linha["UnitPrice"]+" - "+linha["CategoryName"]);

   6:             }



Acredito que este simples exemplo possa ajudar no desenvolvimento de sua aplicação e mostre também a quantidade de funcionalidades existentes no Entity Framework 4.

[]s,

Carlos dos Santos.

May 25

Palestra na Unipar de Paranavaí/PR

Ontem (24/05/2010) eu e o Márcio Althmann realizamos uma palestra na Unipar de Paranavaí/PR onde tivemos a oportunidade de mostrar as novidades do novo Visual Studio 2010 e do Silverlight 4.

Gostaria de agradecer ao nosso amigo Rodrigo Ghedin, do famoso site WinAjuda e MVP assim como eu, pelo convite e pela oportunidade de mostrarmos um pouco de tecnologia neste evento.

Agradecemos também a direção da Unipar pelo espaço e pela colaboração na divulgação do evento.

Vejam as fotos:

DSC04855
Momentos antes da palestra.

DSC04873
Palestra sobre as novidades do Visual Studio 2010.
DSC04875 DSC04877 DSC04883
Tivemos um auditório lotado, muito bom mesmo!!!
DSC04885 DSC04899
Márcio falando sobre Silverlight 4.
DSC04905

[]s,
Carlos dos Santos.

Apr 14

Evento sobre Visual Studio 2010 na Unioeste em Cascavel

Agora pouco eu e o Alexsandro Salmazo (funcionário da Microsoft) fizemos uma palestra na Unioeste em Cascavel/PR.

O Salmazo abriu o evento falando sobre diversas tecnologias e aplicações que a Microsoft possui, foi muito bom!!!

Depois eu falei sobre várias funcionalidades do novo Visual Studio 2010, EF 4, WPF, Silverlight e Azure, enfim, fiz um overview da plataforma .Net e do Visual Studio 2010.

Agradecemos o convite da universidade e esperamos voltar lá em breve.

Vejam as fotos:

DSC04746 DSC04747 DSC04748 DSC04750 DSC04751 DSC04752 DSC04753 DSC04754 DSC04755 DSC04756

[]s,
Carlos dos Santos.

Apr 14

Evento sobre Visual Studio 2010 na PUC em Londrina

Realizamos ontem (13/04) mais um evento de Visual Studio 2010, desta vez na PUC de Londrina.

O André Nobre deu um show nas novidades do Visual Studio 2010, depois eu falei do Entity Framework 4.0 e para finalizar o Márcio Althmann falou do Silverlight 4.

Agradecemos a PUC oportunidade e esperamos estar em breve realizando novos eventos por lá.

Vejam as fotos:

DSC02453
Finalmente o André fez um PPT com os dados dele. rsrsrs
DSC02458 DSC02470 DSC02480  DSC02483 
Olha como cara tá gordo!!!

[]s,
Carlos dos Santos.