Aprendendo Entity Framework - Parte 1 de N - Introdução ao Entity Framework - André Alves de Lima
Se você algum dia já procurou conteúdo sobre Entity Framework na internet, muito provavelmente você percebeu que já existem diversos artigos, tutoriais e cursos sobre essa tecnologia. Mas, mesmo assim, depois desse assunto ter sido um dos mais votados na minha última pesquisa de temas, resolvi criar uma série própria sobre ele aqui no site. O primeiro artigo dessa série será uma introdução ao Entity Framework. Entenderemos as diferenças entre Entity Framework Full e Entity Framework Core, Code First e Database First, entre outras coisas. Ficou interessado(a)? Então, lá vamos nós!
Antes de começar essa série, quero deixar explícito aqui na seção de "disclaimer" que eu particularmente nunca utilizei o Entity Framework em produção em nenhuma aplicação. Todos os projetos que eu participei profissionalmente até hoje utilizaram ADO.NET sem nenhum ORM. Conheço os conceitos do Entity Framework, sei como ele funciona e já construí alguns projetos de exemplo, mas nada que tenha ido para produção.
"Mas, pera aí, você nunca utilizou Entity Framework em produção, então qual a sua autoridade para falar sobre esse assunto?"
Pois bem, se você está se perguntando isso, aqui vai a minha explicação. Eu acho que justamente essa minha falta de experiência em produção com o Entity Framework será o grande diferencial dessa série. A maioria do conteúdo sobre Entity Framework que você vê por aí são de pessoas que já têm bastante experiência com ele. E isso muitas vezes acaba fazendo com que o conteúdo fique complicado de entender, uma vez que o autor assume que a audiência já tem a mesma experiência dele. No meu caso, eu vou passar por algumas dificuldades durante a produção dessa série, e eu pretendo detalhar todas essas dificuldades aqui para você também.
Na minha opinião, existem duas maneiras de realmente dominarmos qualquer assunto técnico que seja: 1) colocando uma aplicação em produção utilizando a tecnologia em questão; 2) ensinando enquanto aprende. A ideia é aprofundar os meus conhecimentos sobre Entity Framework e, ao mesmo tempo, documentar os meus aprendizados aqui no site. Espero que isso acabe te ajudando de alguma maneira.
Primeiramente, o que é esse tal de Entity Framework que o pessoal tanto fala por aí? Bom, de maneira extremamente resumida, o Entity Framework é um framework ORM para .NET desenvolvido pela Microsoft (e atualmente open source), cuja primeira versão saiu em 2008 no .NET Framework 3.5 SP1. E o que viria a ser um ORM?
ORM é uma abreviação de "object-relational mapping", ou seja, mapeamento objeto-relacional. De maneira bem simplificada, frameworks ORM possibilitam o mapeamento das tabelas do banco com classes do seu projeto. Ou seja, se você tem uma tabela de "Clientes" no seu banco de dados, um framework ORM facilita o mapeamento dessa tabela com uma possível classe "Cliente" do seu projeto.
Quando implementamos a camada de acesso a dados da nossa aplicação, existem basicamente duas maneiras de nos comunicarmos com o banco de dados: ou utilizamos ADO.NET puro (com as classes DbConnection, DbCommand, etc., escrevendo manualmente os comandos SQL para recuperarmos e salvarmos os dados no banco) ou utilizamos um ORM (que por trás dos panos faz toda a mágica com o ADO.NET, criando os comandos SQL automaticamente). Se você quiser saber mais sobre as vantagens e desvantagens de cada um desses modelos, confira este vídeo do André Baltieri.
Além desses dois modelos, existe também um meio termo, que são os micro-ORMs. Caso você se interesse por esse meio termo, confira o meu artigo sobre Dapper, que é o micro-ORM para .NET mais conhecido atualmente.
No ecossistema .NET, o Entity Framework não é o único ORM disponível. O outro ORM mais conhecido para essa plataforma é o NHibernate, que é um porte para .NET do Hibernate (originalmente desenvolvido em Java). Como você pode perceber pelo título, essa série focará no Entity Framework. Talvez mais para a frente eu escreva uma outra série com o mesmo conteúdo em NHibernate (que eu não tenho absolutamente nenhuma experiência até agora).
Entity Framework Full? Entity Framework Core?
Até o começo de 2016, a Microsoft vinha lançando versões sequenciais do Entity Framework. Ela começou com a versão 1, pulou alguns números, aí tivemos a versão 4, a versão 5 e chegamos na versão 6 no final de 2013. Tudo estava caminhando normalmente, até que ela decidiu inventar um .NET Framework novo, do zero, que seria multi-plataforma. É o .NET Core que você provavelmente já deve ter ouvido alguma coisa sobre ele.
Junto com essa iniciativa do .NET Core, o time de acesso a dados do .NET resolveu re-escrever o Entity Framework também. Essa nova versão, desenvolvida do zero, também seria multi-plataforma, nos mesmos moldes do .NET Core. Depois de algumas discussões sobre o nome, a Microsoft nomeou essa nova versão do Entity Framework como "Entity Framework Core".
Os conceitos básicos do Entity Framework Core são os mesmos do Entity Framework "full" (que veremos no artigo de hoje). O grande problema do Entity Framework Core é que ele não tem todas as funcionalidades disponíveis no Entity Framework "full". Muita gente diz que ele ainda não está estável o suficiente para ser utilizado em produção. Como eu nunca utilizei nenhum deles em produção, eu não posso dar uma opinião sobre isso com propriedade, mas eu particularmente só utilizaria o Entity Framework Core hoje em dia caso eu realmente tivesse que desenvolver um projeto com o .NET Core (o que não foi o caso até agora).
Eu optei por utilizar o Entity Framework "full" nessa série. Quem sabe quando chegarmos no final dela, eu não faça um porte para o Entity Framework Core para vermos as surpresas que encontraremos na conversão.
Code First? Database First?
Uma vez entendido o conceito básico do Entity Framework, a pergunta que vem em seguida é: code first ou database first? Essas são as duas maneiras de trabalharmos com o Entity Framework. A grande diferença entre essas duas sistemáticas está no objeto que será a base para o mapeamento. No code first, as classes do projeto são a base para o mapeamento (elas são utilizadas para gerar as tabelas do banco de dados). Já no database first, temos o inverso (as tabelas do banco são utilizadas para gerarmos as classes do projeto).
Eu vejo o code first sendo muito mais utilizado do que o database first, por isso nós utilizaremos essa sistemática durante toda essa série. Assim que terminarmos toda a explicação do code first, utilizaremos o banco gerado pelo Entity Framework em um exemplo com database first.
Exemplo base: dados em memória
Para interagirmos com o banco de dados, criaremos uma aplicação muito simples utilizando Windows Forms. Essa aplicação terá inicialmente duas classes de domínio: CategoriaProduto e Produto. Mais para a frente expandiremos esse domínio para abordarmos funcionalidades mais avançadas do Entity Framework.
Dito isso, em um projeto Windows Forms, crie uma nova pasta chamada "Model" e adicione as classes CategoriaProduto e Produto dentro dessa pasta:
Feito isso, vamos adicionar um grid no formulário com as colunas referentes às propriedades da classe Produto:
No code-behind do formulário, vamos adicionar duas listas (uma de categorias e outra de produtos). Criaremos algumas instâncias padrão de categorias e configuraremos o data binding:
private List<Model.CategoriaProduto> _categorias = new List<Model.CategoriaProduto>();
private List<Model.Produto> _produtos = new List<Model.Produto>();
_categorias.Add(new Model.CategoriaProduto() { Id = 1, Nome = "Smartphone" });
_categorias.Add(new Model.CategoriaProduto() { Id = 2, Nome = "Computador" });
_categorias.Add(new Model.CategoriaProduto() { Id = 3, Nome = "Máquina fotográfica" });
categoriaColumn.DataSource = _categorias;
categoriaColumn.ValueMember = "Id";
categoriaColumn.DisplayMember = "Nome";
dataGridViewProdutos.DataSource = _produtos;
Private Categorias = New List(Of CategoriaProduto)()
Private Produtos = New List(Of Produto)()
Categorias.Add(New CategoriaProduto() With {.Id = 1, .Nome = "Smartphone"})
Categorias.Add(New CategoriaProduto() With {.Id = 2, .Nome = "Computador"})
Categorias.Add(New CategoriaProduto() With {.Id = 3, .Nome = "Máquina fotográfica"})
CategoriaColumn.DataSource = Categorias
CategoriaColumn.ValueMember = "Id"
CategoriaColumn.DisplayMember = "Nome"
DataGridViewProdutos.DataSource = Produtos
Execute a aplicação e veja que nós teremos um comportamento estranho. Apesar de termos definido as colunas do grid no designer, ao executarmos a aplicação, novas colunas foram criadas para cada propriedade da classe Produto:
Isso aconteceu porque eu esqueci de configurar a propriedade "DataPropertyName" das colunas do grid. Nós temos que configurar o "DataPropertyName" das colunas do grid com o nome correspondente das propriedades da classe Produto:
Se executarmos novamente a aplicação, veremos que, ainda sim, uma coluna a mais será adicionada para a propriedade "Categoria". Isso acontece porque o grid não consegue entender direito que já criamos um ComboBox para essa propriedade. Portanto, vamos desabilitar a criação automática de colunas do grid configurando a propriedade "AutoGenerateColumns" como "false":
dataGridViewProdutos.AutoGenerateColumns = false;
DataGridViewProdutos.AutoGenerateColumns = False
Ao executarmos mais uma vez a aplicação, nós veremos o resultado final do grid:
Mas, por que é que não conseguimos adicionar nenhuma linha no grid? Isso acontece porque nós criamos instâncias de "List" para a lista de categorias e produtos, mas na verdade nós precisamos de instâncias de "BindingList" (que permitirá adicionar e remover linhas do grid):
private BindingList<Model.CategoriaProduto> _categorias = new BindingList<Model.CategoriaProduto>();
private BindingList<Model.Produto> _produtos = new BindingList<Model.Produto>();
Private Categorias = New System.ComponentModel.BindingList(Of CategoriaProduto)()
Private Produtos = New System.ComponentModel.BindingList(Of Produto)()
Execute a aplicação novamente e receba esse belo erro:
Poxa vida, quando é que finalmente a aplicação funcionará como esperado? Não se preocupe, estamos quase lá. Esse erro aconteceu porque a propriedade "CategoriaId" da classe Produto é um inteiro, e o valor padrão de variáveis inteiras é zero. Ou seja, quando uma nova linha é criada no grid, a propriedade "CategoriaId" receberá o valor zero, e o grid não conseguirá encontrar um valor correspondente no ComboBox de categorias. Para contornarmos esse erro, ou nós alteramos a propriedade "CategoriaId" na classe produto para um "int?" (inteiro que aceita nulos) ou nós ignoramos o erro no grid. Como nós não queremos que a categoria possa ser vazia, nós ignoraremos o erro do grid implementando um "handler" vazio para o evento "DataError":
dataGridViewProdutos.DataError += (s, e) => { };
AddHandler DataGridViewProdutos.DataError, Sub(s, e2)
Pronto! Agora sim, execute a aplicação e veja que nós podemos adicionar produtos no nosso grid:
E como é que nós fazemos para salvar esses produtos em um banco de dados? É aí que entra o Entity Framework!
Como instalar o Entity Framework?
A instalação do Entity Framework se dá através do NuGet. Portanto, a primeira coisa que temos que fazer é abrirmos a tela de gerenciamento de pacotes do NuGet:
Em seguida, nós faremos uma busca por "entity" e instalaremos o pacote chamado "EntityFramework":
E com isso o Entity Framework foi instalado no nosso projeto! Simples assim. Uma coisa importante que temos que notar é que a instalação do Entity Framework faz algumas alterações no arquivo app.config. Observe, principalmente, o conteúdo da tag "entityFramework":
Note que, por padrão, o Entity Framework utilizará o provider do SQL Server e o LocalDb como destino do banco de dados. Nesse artigo nós não alteraremos nada na configuração. Em uma outra oportunidade eu mostrarei para você como podemos fazer para trocarmos o provider do banco de dados, bem como a string de conexão que será considerada pelo Entity Framework.
Exemplo simples com Code First
Agora que nós já temos a nossa lista de categorias e produtos armazenadas em memória, vamos ver como nós podemos fazer para gerarmos um banco de dados com essa estrutura utilizando o Entity Framework. A primeira coisa que temos que fazer é criarmos um contexto. O contexto terá a lista de entidades que serão gerenciadas (no nosso caso, CategoriaProduto e Produto), bem como configurações adicionais do Entity Framework.
A classe de contexto deve sempre herdar de DbContext (que é uma classe base do Entity Framework). Dentro do contexto, devemos criar uma propriedade "DbSet" para cada entidade. Esses "DbSets" serão, em linhas gerais, as tabelas do banco de dados. No nosso caso, nós teremos um DbSet para a classe CategoriaProduto e outro DbSet para a classe Produto. Além disso, no construtor do contexto, nós adicionaremos as categorias padrão caso a tabela de categorias ainda esteja vazia:
public class ContextoBD : System.Data.Entity.DbContext
public ContextoBD() : base()
CategoriaProduto.Add(new Model.CategoriaProduto() { Id = 1, Nome = "Smartphone" });
CategoriaProduto.Add(new Model.CategoriaProduto() { Id = 2, Nome = "Computador" });
CategoriaProduto.Add(new Model.CategoriaProduto() { Id = 3, Nome = "Máquina fotográfica" });
Public Class ContextoBD
Public Property CategoriaProduto As System.Data.Entity.DbSet(Of CategoriaProduto)
Public Property Produto As System.Data.Entity.DbSet(Of Produto)
If Not CategoriaProduto.Any() Then
CategoriaProduto.Add(New CategoriaProduto() With {.Id = 1, .Nome = "Smartphone"})
CategoriaProduto.Add(New CategoriaProduto() With {.Id = 2, .Nome = "Computador"})
CategoriaProduto.Add(New CategoriaProduto() With {.Id = 3, .Nome = "Máquina fotográfica"})
Em seguida, nós alteraremos o código do nosso formulário para que ele utilize esse contexto que acabamos de criar. Agora nós não precisaremos mais de "BindingLists" para alimentarmos o ComboBox e o grid. Nós faremos o data binding direto com os DbSets que criamos no nosso contexto:
private ContextoBD _bd = new ContextoBD();
categoriaColumn.DataSource = _bd.CategoriaProduto;
dataGridViewProdutos.DataSource = _bd.Produto;
Private BD As ContextoBD = New ContextoBD()
CategoriaColumn.DataSource = BD.CategoriaProduto
DataGridViewProdutos.DataSource = BD.Produto
Se executarmos a aplicação depois dessas alterações, nós receberemos o seguinte erro:
Veja só a mensagem mais detalhada:
O que o erro quer dizer é que nós não podemos simplesmente fazer um data binding direto com o DbSet. Ao invés disso, nós temos que fazer o data binding com a propriedade "Local" dos respectivos DbSets, convertendo para um BindingList (com o método "ToBindingList"). O problema é que o método "ToBindingList" fica meio que escondido (mais detalhes nesta thread do StackOverflow). Como ele é um "extension method", nós só conseguiremos utilizá-lo se adicionarmos um "using" (ou "Imports" no VB.NET) para o namespace "System.Data.Entity":
Agora sim, com esse namespace referenciado, nós conseguiremos fazer o data binding da maneira correta:
categoriaColumn.DataSource = _bd.CategoriaProduto.Local.ToBindingList();
dataGridViewProdutos.DataSource = _bd.Produto.Local.ToBindingList();
CategoriaColumn.DataSource = BD.CategoriaProduto.Local.ToBindingList()
DataGridViewProdutos.DataSource = BD.Produto.Local.ToBindingList()
Entretanto, se nós executarmos a aplicação, nós veremos que a lista de categorias estará vazia:
Isso acontece porque, por padrão, o Entity Framework não carrega nada em memória até o momento em que acessamos os DbSets. E como estamos utilizando a propriedade "Local" dos DbSets, nós precisamos explicitamente chamar o método "Load" dos DbSets para que os dados sejam carregados em memória:
_bd.CategoriaProduto.Load();
_bd.Produto.Load();
BD.CategoriaProduto.Load()
BD.Produto.Load()
Agora sim, se executarmos a aplicação, veremos que a lista de categorias será carregada corretamente com os registros padrão. Porém, como é que nós fazemos para salvar as alterações no banco de dados? Não se preocupe, isso é muito fácil. Nós só temos que chamar o método "SaveChanges" do contexto e ele se encarregará de salvar as alterações no banco de dados.
Para vermos esse efeito na prática, vamos adicionar um novo botão embaixo do nosso grid:
No clique desse botão, vamos executar o método "SaveChanges" do nosso contexto:
_bd.SaveChanges();
Private Sub BtSalvar_Click(sender As Object, e As EventArgs) Handles BtSalvar.Click
Pronto! Agora sim, se executarmos a aplicação, inserirmos um registro no grid e clicarmos no botão "Salvar", os dados serão salvos no banco de dados. Você poderá conferir se está funcionando corretamente ao fechar e abrir a aplicação novamente. Nesse caso, o registro salvo anteriormente deverá ser carregado no grid:
Onde o banco foi criado?
OK, gostei. Tudo isso parece muito mágico. Mas, onde é que os dados foram salvos? Onde está o banco de dados que foi criado? Pois bem, como vimos na etapa da instalação do Entity Framework, por padrão, ele utiliza o LocalDb. Dessa forma, se analisarmos em tempo de execução o conteúdo da propriedade "Database.Connection.ConnectionString" do nosso contexto, veremos que ele estará apontando para o LocalDb:
Se abrirmos o LocalDb com o SQL Server Management Studio, veremos que o banco foi criado e os dados foram realmente salvos:
A única coisa estranha aqui está nos nomes das tabelas. Por que é que elas foram chamadas de "CategoriaProdutoes" e "Produtoes"? Que coisa mais esquisita, não é mesmo? Pois bem, por padrão, o Entity Framework tenta pluralizar os nomes das tabelas no banco de dados. Obviamente, ao utilizarmos os nomes das entidades em português, isso vira uma verdadeira catástrofe. Será que não teria um jeito de alterar isso? Tem sim, nós só precisamos desativar a pluralização dos nomes de tabelas.
Desativando a pluralização
O mapeamento objeto-relacional do Entity Framework utiliza uma variedade de convenções. Uma dessas convenções padrão é a pluralização de nomes de tabelas, que é justamente o que queremos desativar. Para alterarmos as convenções do Entity Framework, nós temos que dar um "override" no método "OnModelCreating" do nosso contexto, onde utilizaremos a propriedade "Conventions" do parâmetro "modelBuilder" para ativarmos ou desativarmos convenções específicas.
Para desativarmos a pluralização, nós temos que dar um "Remove" na convenção chamada "PluralizingTableNameConvention". Veja como é que fica o código:
O problema é que, ao alterarmos uma convenção desse tipo, o Entity Framework não conseguirá mais utilizar o banco que tinha sido criado anteriormente. Se tentarmos executar a aplicação após essa alteração, nós receberemos esse erro:
Nesse caso, ou nós alteramos os nomes das tabelas manualmente no banco já existente ou nós deletamos o banco para que ele seja criado novamente. Como estamos ainda em fase de desenvolvimento, nós podemos simplesmente deletar o banco, aí na próxima execução o Entity Framework criará novamente as tabelas com os nomes não pluralizados:
Obviamente, se a aplicação já estiver em produção, fica inviável de desativar a pluralização, mas acredito que esse não seja um cenário que aconteça em aplicações "de verdade".
Esse artigo já está ficando mais extenso do que eu gostaria, portanto, vou parar por aqui. Aproveito para deixar uma lista de possíveis temas para os próximos artigos dessa série (não necessariamente nessa ordem):
– Trocando o provider do banco de dados
– Entity Framework Migrations
– Mapeamentos com Data Annotations e Fluent API
– Relacionamentos complexos e heranças
– Sentenças customizadas e stored procedures
– Utilização do padrão Repository
– Intercepção das consultas geradas
– Exemplo simples com Database First
Se você tiver alguma ideia de outros tópicos para que eu aborde nessa série, é só avisar nos comentários.
O Entity Framework é o ORM open-source para .NET desenvolvido pela Microsoft. Em alguns tipos de aplicação, ele acaba facilitando muito a nossa vida, uma vez que nós conseguimos utilizar as classes do nosso projeto praticamente como tabelas do nosso banco de dados.
Essa série tem como objetivo detalhar o funcionamento do Entity Framework. No artigo de hoje vimos uma introdução a essa tecnologia, com os conceitos básicos e a implementação de um exemplo simples utilizando a metodologia code first. Nos próximos artigos da série nós veremos conceitos mais avançados. Caso você tenha alguma sugestão de temas específicos que eu deva abordar nessa série, é só deixar um comentário logo abaixo.
https://pixabay.com/en/database-schema-data-tables-schema-1895779/
Imprimindo direto na impressora com o Crystal Reports Suporte ao Crystal Reports no Visual Studio 2017
25 thoughts on "Aprendendo Entity Framework – Parte 1 de N – Introdução ao Entity Framework"
Se possível gostaria que falasse desse tema no próximo artigo da serie:
Mapeamentos com Data Annotations e Fluent API
Valeu, Anderson! Fico feliz que você tenha gostado.. :)
Obrigado pela sugestão! Coloquei esse tema na minha agenda.. Pode ser que demore um tempo até eu conseguir escrever sobre ele, mas garanto que um dia sai..
13 de dezembro de 2017 às 18:35
Legal Andre! Eu também sempre usei ADO nos projetos de produção pois em termos de performance não tem o que discutir. Eu já usei EF em alguns cenários onde precisava de uns CRUDs e não me importei com performance. Vou acompanhar essa série tbm!! Absz
14 de dezembro de 2017 às 9:38
Fala Ray, obrigado pelo comentário e valeu por acompanhar a série.. :)
Muito bom Andre ! Seria legal se desse pra falar também um pouco LINQ TO SQL, para mapeamento de tapebas, views e procedures. Abraço !
18 de dezembro de 2017 às 5:55
Você utiliza LINQ to SQL nos seus projetos (ou pensa em utilizar)? Eu não acompanhei muito o histórico, mas até onde eu sei o LINQ to SQL não é mais evoluído e o Entity Framework entrou no lugar dele, com mais funcionalidades, etc.. Ou no lugar de LINQ to SQL você quis dizer o próprio Entity Framework?
Excelente artigo… Muito bom..
Valeu, Elessandro! Muito obrigado pelo comentário!
Eronildo Marques disse:
Primeiro de tudo parabéns pelo bom post, André!
Gostaria a título de sugestão que, quando possível, publicasse algo a respeito de como o Entity Framework lida com segurança e controle de acesso.
18 de dezembro de 2017 às 6:05
Olá Eronildo, muito obrigado pelo comentário! Fico feliz que você tenha gostado..
Quanto à sua sugestão, você poderia explicar mais detalhadamente? O Entity Framework recebe as credenciais do banco pela connection string (como quando você abre uma DbConnection com o ADO.NET puro).. O que você quis dizer exatamente com "segurança e controle de acesso" no Entity Framework?
Agradeço pelo retorno. Bem, quanto ao que me refiro à segurança é relativo à proteção dos dados propriamente dito, contra o ataque de hackers e coisa assim, por exemplo. Quero saber que recursos o Entity Framework tem para lidar com situações assim. Quanto ao controle de acesso me refiro ao acesso de dados por múltiplos usuários ao mesmo tempo e aos mesmos dados, que recursos são apresentados pelo Entity Framework para lidar com essa situação. São dúvidas minhas que gostaria de tê-las sarnadas se for possível. Mais uma vez agradeço pela oportunidade e fico na expectativa das novas postagens do Entity Framework, as quais agora muito me interessam.
Muito obrigado pelas explicações.. Quanto ao esquema de proteção, não sei te dizer, preciso pesquisar.. Mas sinceramente não sei como o Entity Framework poderia fazer alguma coisa nesse sentido, uma vez que ele só é uma camada "intermediária" entre a aplicação e o banco de dados.. Ele só facilita a leitura e escrita de informações no banco de dados.. Mas, enfim, vou colocar na minha lista..
E quanto ao acesso de múltiplos usuários ao mesmo tempo, o Entity Framework resolve isso da mesma maneira que o ADO.NET puro resolve, ou seja, através de transações.. Quero preparar um exemplo de transações com o Entity Framework nessa série.. Espero que eu consiga abordar esse tema no ano que vem..
Fico feliz com suas observações e interesse em pontual as minhas dúvidas. Ficarei no aguardo das suas próximas postagens sobre o Entity Framework, as quais, acredito, serão amplas e elucidativas para todos nós que nos interessamos por essa tecnologia.
2 de janeiro de 2018 às 5:58
Muito obrigado, Eronildo! Assim que tiver alguma novidade sobre esses tópicos, eu te aviso..
Gilberto Lima dos Santos disse:
André, gostei muito do seu post.
Vejo pelos comentários que existem muitas duvidas referente ao assunto, por isto a importância de se ter onde pesquisar e resolve-las, vejo também a maneira de colocar nos temas as dificuldades inicias e a simplicidade em que você esta utilizando na abordagem do assunto uma vez que existem varias maneiras de se chegar a uma solução. Como sempre sua humildade e de se admirar..
Sugiro como tema para próxima abordagem:
– Trocando o provider do banco de dados.
27 de dezembro de 2017 às 5:52
Muito obrigado pelo comentário e pelos elogios.. :)
Anoitei aqui a sua sugestão e espero que eu consiga abordar esse tema em algum momento do próximo ano..
Um excelente 2018 aí para você!
Mais uma vez parabéns pelo artigo , sempre muito explicativo.
Ja faz um tempo que mexi com Entity Framework e lembro que fiquei instigado sobre a o uso de Procedures com ele e de Notificações do Banco ao realizar notificações (SqlDependency) , gostaria de sugerir estes dois assuntos para próximas abordagens, se possível.
Quanto ao esquema de utilização de procedures, já coloquei aqui na minha lista.. Espero que eu consiga escrever sobre esse tema em algum momento no próximo ano..
Já quanto à sua segunda sugestão (notificações do banco ao realizar alterações – SqlDependency), eu nunca trabalhei com ele nem no ADO.NET puro.. Não tenho ideia de como integrá-lo no Entity Framework.. Mas, de qualquer forma, coloquei esse tema aqui na minha lista também..
Nailton Magalhaes disse:
21 de dezembro de 2017 às 2:08
Ótimo post, gostei também do vídeo do André Baltieri, não fazia ideia da diferença que havia entre usar o ADO.Net e usar ORM. Estou ansioso para ver os próximos posts sobre o assunto. Valeu André Limpa.
Pois é, muitas vezes utilizamos uma tecnologia e nem sabemos o que tem por trás dela.. No caso do Entity Framework é importante esse conhecimento, caso performance seja um fator primordial na aplicação que está sendo desenvolvida.. :)
Olá André, tudo bem? A minha dúvida é em relação à instalação para uso do Framework… Ela deve ser instalada a cada projeto, ou só na primeira vez do uso?
Tenha um ótimo 2018 com muto sucesso!
8 de janeiro de 2018 às 8:29
O Entity Framework é baixado via NuGet e deve ser instalado uma única vez para cada projeto que fará uso dele (como qualquer outra biblioteca baixada pelo NuGet)..
Desacoplando o acesso a dados da aplicação com o padrão Repository e Unit of Work - André Alves de Lima disse:
[…] do NuGet. Se ainda não conhece nada sobre o Entity Framework, dê uma olhada primeiro no meu artigo introdutório sobre o Entity Framework. Ele é leitura obrigatória se você ainda não conhece os conceitos básicos do Entity […]
José Eduardo Alayon disse:
Gostei do artigo mas devido ao meu grau de conhecimento não consegui associar o DataGridView com a classe produto. Como faço?
Mas é justamente isso que eu mostro no artigo.. Em qual parte você ficou com dúvida exatamante? De mais detalhes da dificudlade que você está tendo..