13 12 2017

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!

Disclaimer

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.

O que é Entity Framework?

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:

    // C#
    public class CategoriaProduto
    {
        public int Id { get; set; }
        public string Nome { get; set; }
    }

    // C#
    public class Produto
    {
        public int Id { get; set; }
        public string Descricao { get; set; }
        public CategoriaProduto Categoria { get; set; }
        public int CategoriaId { get; set; }
        public DateTime DataCadastro { get; set; }
        public decimal ValorUnitario { get; set; }
    }

' VB.NET
Public Class CategoriaProduto
    Public Property Id As Integer
    Public Property Nome As String
End Class

' VB.NET
Public Class Produto
    Public Property Id As Integer
    Public Property Descricao As String
    Public Property Categoria As CategoriaProduto
    Public Property CategoriaId As Integer
    Public Property DataCadastro As DateTime
    Public Property ValorUnitario As Decimal
End Class

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:

        // C#
        private List<Model.CategoriaProduto> _categorias = new List<Model.CategoriaProduto>();
        private List<Model.Produto> _produtos = new List<Model.Produto>();

        public Form1()
        {
            InitializeComponent();

            _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;
        }

    ' VB.NET
    Private Categorias = New List(Of CategoriaProduto)()
    Private Produtos = New List(Of Produto)()

    Private Sub Form1_Load(sender As Object, e As EventArgs) Handles MyBase.Load
        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
    End Sub

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“:

            // C#
            dataGridViewProdutos.AutoGenerateColumns = false;
            dataGridViewProdutos.DataSource = _produtos;

            ' VB.NET
            DataGridViewProdutos.AutoGenerateColumns = False
            DataGridViewProdutos.DataSource = Produtos

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):

        // C#
        private BindingList<Model.CategoriaProduto> _categorias = new BindingList<Model.CategoriaProduto>();
        private BindingList<Model.Produto> _produtos = new BindingList<Model.Produto>();

    ' VB.NET
    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“:

            // C#
            dataGridViewProdutos.AutoGenerateColumns = false;
            dataGridViewProdutos.DataSource = _produtos;
            dataGridViewProdutos.DataError += (s, e) => { };

        ' VB.NET
        DataGridViewProdutos.AutoGenerateColumns = False
        DataGridViewProdutos.DataSource = Produtos
        AddHandler DataGridViewProdutos.DataError, Sub(s, e2)
                                                   End Sub

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:

    // C#
    public class ContextoBD : System.Data.Entity.DbContext
    {
        public System.Data.Entity.DbSet<Model.CategoriaProduto> CategoriaProduto { get; set; }
        public System.Data.Entity.DbSet<Model.Produto> Produto { get; set; }

        public ContextoBD() : base()
        {
            if (!CategoriaProduto.Any())
            {
                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" });
                SaveChanges();
            }
        }
    }

' VB.NET
Public Class ContextoBD
    Inherits System.Data.Entity.DbContext

    Public Property CategoriaProduto As System.Data.Entity.DbSet(Of CategoriaProduto)
    Public Property Produto As System.Data.Entity.DbSet(Of Produto)

    Public Sub New()
        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"})
            SaveChanges()
        End If
    End Sub
End Class

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:

        // C#
        private ContextoBD _bd = new ContextoBD();

        public Form1()
        {
            InitializeComponent();

            categoriaColumn.DataSource = _bd.CategoriaProduto;
            categoriaColumn.ValueMember = "Id";
            categoriaColumn.DisplayMember = "Nome";

            dataGridViewProdutos.AutoGenerateColumns = false;
            dataGridViewProdutos.DataSource = _bd.Produto;
            dataGridViewProdutos.DataError += (s, e) => { };
        }

    ' VB.NET
    Private BD As ContextoBD = New ContextoBD()

    Private Sub Form1_Load(sender As Object, e As EventArgs) Handles MyBase.Load
        CategoriaColumn.DataSource = BD.CategoriaProduto
        CategoriaColumn.ValueMember = "Id"
        CategoriaColumn.DisplayMember = "Nome"
        DataGridViewProdutos.AutoGenerateColumns = False
        DataGridViewProdutos.DataSource = BD.Produto
        AddHandler DataGridViewProdutos.DataError, Sub(s, e2)
                                                   End Sub
    End Sub

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“:

// C#
using System.Data.Entity;

' VB.NET
Imports System.Data.Entity

Agora sim, com esse namespace referenciado, nós conseguiremos fazer o data binding da maneira correta:

            // C#
            categoriaColumn.DataSource = _bd.CategoriaProduto.Local.ToBindingList();
            categoriaColumn.ValueMember = "Id";
            categoriaColumn.DisplayMember = "Nome";

            dataGridViewProdutos.AutoGenerateColumns = false;
            dataGridViewProdutos.DataSource = _bd.Produto.Local.ToBindingList();
            dataGridViewProdutos.DataError += (s, e) => { };

        ' VB.NET
        CategoriaColumn.DataSource = BD.CategoriaProduto.Local.ToBindingList()
        CategoriaColumn.ValueMember = "Id"
        CategoriaColumn.DisplayMember = "Nome"
        DataGridViewProdutos.AutoGenerateColumns = False
        DataGridViewProdutos.DataSource = BD.Produto.Local.ToBindingList()
        AddHandler DataGridViewProdutos.DataError, Sub(s, e2)
                                                   End Sub

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:

            // C#
            _bd.CategoriaProduto.Load();
            categoriaColumn.DataSource = _bd.CategoriaProduto.Local.ToBindingList();
            categoriaColumn.ValueMember = "Id";
            categoriaColumn.DisplayMember = "Nome";

            _bd.Produto.Load();
            dataGridViewProdutos.AutoGenerateColumns = false;
            dataGridViewProdutos.DataSource = _bd.Produto.Local.ToBindingList();
            dataGridViewProdutos.DataError += (s, e) => { };

        ' VB.NET
        BD.CategoriaProduto.Load()
        CategoriaColumn.DataSource = BD.CategoriaProduto.Local.ToBindingList()
        CategoriaColumn.ValueMember = "Id"
        CategoriaColumn.DisplayMember = "Nome"

        BD.Produto.Load()
        DataGridViewProdutos.AutoGenerateColumns = False
        DataGridViewProdutos.DataSource = BD.Produto.Local.ToBindingList()
        AddHandler DataGridViewProdutos.DataError, Sub(s, e2)
                                                   End Sub

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:

        // C#
        private void btSalvar_Click(object sender, EventArgs e)
        {
            _bd.SaveChanges();
        }

    ' VB.NET
    Private Sub BtSalvar_Click(sender As Object, e As EventArgs) Handles BtSalvar.Click
        BD.SaveChanges()
    End Sub

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:

        // C#
        protected override void OnModelCreating(System.Data.Entity.DbModelBuilder modelBuilder)
        {
            base.OnModelCreating(modelBuilder);
            modelBuilder.Conventions.Remove<System.Data.Entity.ModelConfiguration.Conventions.PluralizingTableNameConvention>();
        }

    ' VB.NET
    Protected Overrides Sub OnModelCreating(ByVal modelBuilder As System.Data.Entity.DbModelBuilder)
        MyBase.OnModelCreating(modelBuilder)
        modelBuilder.Conventions.Remove(Of System.Data.Entity.ModelConfiguration.Conventions.PluralizingTableNameConvention)()
    End Sub

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“.

Possíveis temas para próximos artigos

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
– Transações
– 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.

Baixe o projeto de exemplo

Para baixar o projeto de exemplo desse artigo, assine a minha newsletter. Ao fazer isso, além de ter acesso ao projeto, você receberá um e-mail toda semana sobre o artigo publicado e ficará sabendo também em primeira mão sobre o artigo da próxima semana, além de receber dicas “bônus” que eu só compartilho por e-mail. Inscreva-se utilizando o formulário no final do artigo.

Concluindo

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.

Até a próxima!

André Lima

Image by Pixabay used under Creative Commons
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