E o ADO.NET nunca deve deixar de ser utilizado

Comumente recebo e-mails sobre: “Qual tecnologia de acesso a dados devo utilizar no meu projeto?”, “O EF é performático o suficiente para fazer isso?”, “Tenho uma rotina de acesso a dados lenta, o que devo fazer?”, “Qual a melhor formar de construir minha camada de acesso a dados?”, etc. A resposta para todas essas perguntas é basicamente a mesma. E sempre acabo me referindo ao ADO.NET como um aliado muito forte (e presente) nas aplicações que desenvolvo. Fato este que gera muita surpresa em todos.

Imagem-Animada-How-Do-You-DoWhat

A construção de camadas de acesso a dados é complexa e exige cuidados. Nos últimos anos muito se tem dito e apoiado o uso de ferramentas de mapeamento objeto-relacional (ORM). Tomo como exemplo este blog, onde muitos de meus posts são sobre o Entity Framework.

Mas mesmo com a quantidade crescente de iniciativas para o emprego de ferramentas ORM, eu ainda sou a favor de uma abordagem híbrida. Acredito que o melhor caminho é o do meio, sendo ele: utilizar ORM quando possível e ADO.NET quando necessário. Ferramentas ORM e ADO.NET podem conviver dentro de um mesmo projeto facilmente. Definir o emprego de cada um dentro de sua camada de acesso a dados exige análise sobre o que será desenvolvido e conhecimento das tecnologias em questão. Quando for necessário inserir, apagar, excluir ou executar consultas sem muita complexidade, as ferramentas ORM podem fazer isso tranquilamente. Quando for preciso inserir um bloco de registros, atualizar um conjunto de linhas ou executar uma query complexa, o ADO.NET estará lá para fazer o trabalho pesado e da forma mais performática possível.

Vamos demonstrar isso com um exemplo simples: dada uma determinada entidade de um sistema, nós devemos construir uma rotina que atualize todos os registros cujo campo de data “Sync” for igual a null. Isso é bastante simples de ser implementado, tanto com o Entity Framework quanto com o ADO.NET.

A implementação com o EF provavelmente seria próxima ao código abaixo:

static void Update() {

    IEnumerable<Entidade> entidades = null;

    using (var contexto = new Contexto()) {

        entidades = contexto.Entidades.Where(e => e.Sync == null);

        if (entidades != null && entidades.Count() > 0) {

            DateTime updateDate = DateTime.Now;
            foreach (var itemEntidade in entidades) {

                itemEntidade.Sync = updateDate;
            }
            contexto.SaveChanges();
        }
    }
}

E a implementação com ADO.NET seria próxima a algo como o código abaixo.

static void Update() {

    using (var conn = new SqlConnection(connectionString)) {

        var command = conn.CreateCommand();
        command.CommandText = "UPDATE Entidades SET Sync = GETDATE() WHERE Sync IS NULL";

        conn.Open();
        command.ExecuteNonQuery();
    }
}

Observando os dois códigos e entendendo a lógica empregada, fica claro que o código com ADO.NET será muito mais performático, além de consumir menos recursos dos servidores de aplicação e de banco de dados.

Lembre-se:

ADO.NET = Performance

Ferramentas ORM = Facilidade de uso

Adotar os dois no mesmo projeto é vantajoso. Eu recomendo e costumo fazer isso.

Operações que envolvam muitos registros ou que possuam muita complexidade em sua iteração com o banco de dados devem ser encapsuladas em stored procedures, além de serem construídas para executarem da forma mais performática possível. Economizar o número de iterações com o banco de dados pode salvar muitos recursos de sua aplicação, pois este é um recurso bastante caro e que pode ser a diferença entre uma aplicação rápida e uma aplicação “carroça”.

As ferramentas ORM são perfeitas para o processo de desenvolvimento, pois elas facilitam nosso trabalho, diminuem a complexidade do código e facilitam a manutenção das aplicação. Seu uso é bastante favorável. Mas saber identificar o momento correto de adotar uma tecnologia ou outra pode determinar o sucesso de sua aplicação.

Por favor, não seja “xiita”, isto é, não escolha uma tecnologia como chave para qualquer problema e feche os olhos para as demais opções. O melhor caminho é o do meio, e adotando diferentes técnicas, paradigmas, modelos e arquiteturas, nós podemos obter muito sucesso desenvolvendo aplicações robustas e performáticas.

Estude, faça experimentos e principamente: entenda que o que deve ser construído deve ser feito na melhor solução possível para o dominio.

 

FH

Anúncios

6 Responses to E o ADO.NET nunca deve deixar de ser utilizado

  1. Jean Gatto says:

    Penso exatamente assim Fernando. Com EF fazemos muitos mais rápido os projetos. Acho a melhor harmonia sempre assim EF + View + Procedure e o mesmo para o ADO.NET + View + Procedure. Uma coisa que percebi, com os SELECTS no EF fica muito difícil de sofre uma injeção no SQL. Já no ADO.NET tem que tomar muito cuidado e parametrizar muito bem. Abraços!

    • Oi Jean, Tudo beleza?
      Obrigado pelo comentário.
      Sim, com o EF é quase impossível sofrer qualquer tipo de SQL Injection. SQL Injection com ADO.NET é mais fácil de acontecer se o desenvolvedor não seguir as suas melhores práticas.

      []s!

  2. Parabéns Fernando, ótimo post.
    Confesso que andava até alguns meses atrás meio xiita em relação ao EF, porém percebi na prática a vantagem de se utilizar o ADO.NET.
    Não sei qual será o assunto de sua palestra (a qual eu com certeza vou assistir) no VS Summit 2014, mas esse estaria de bom tamanho.
    Abs e até lá.

    • Olá Fabiano, tudo beleza?
      Obrigado pelo seu comentário.
      Minha palestra será sobre profiling de aplicações .Net.
      Nos encontramos lá e tomamos um café.

      []s!

  3. Magoo says:

    Fala Fernando, tudo bem?
    Muito bom artigo mas vou tomar a liberdade de complementar ocm algumas coisas.
    Tanto o EF, quanto outros ORMs para a plataforma .NET, fazem uso internamente o ADO.NET, que em minha opinião foi muito bem implementado, o que faz conhecer sua infraestrutura algo índispensável para aumentar a performance de uas aplicações.
    Outro ponto é que mesmo com EF conseguimos enviar cmandos SQL diretamente ao banco de daos usando o ExecSQL e o ExecSQL onde o resultado é materializado em uma coleção de entidades.
    O uso, recomendado para casos extremos onde o SQL gerado não é tão performático, em minha opinião tem de ser bem pensado para que nãio haja, por exemplo, qubra de compatibilidad de dialetos SQL entre bancos dados diferentes caos o produto se destine a este fim, ou seja, rodar em SQL SErver, Oracle e MySQL com a mesma base de código.
    Não acedito em balas de prata, e muito menos em milagres. Sempre uqe escolhemos uma coisa, abrimos mão de outra. Quando optamos pela OO sabemos que perdeemos desempenho, mas ganhamos em facilidade, manutenabilidade e extensibilidade.
    Para a maioria dos cenários, ORM irá lhe attender perfeitamente, já em caso de sistemas de missão crítica, o uso de recursos mais próximos dos dados, como as Stored Procedures, Functions e até mesmo assemblies no SQL Server vão te trazer um diferencial.
    Continue com o ótimo trabalho.
    Abraços,
    Magoo

Deixe um comentário

Preencha os seus dados abaixo ou clique em um ícone para log in:

Logotipo do WordPress.com

Você está comentando utilizando sua conta WordPress.com. Sair / Alterar )

Imagem do Twitter

Você está comentando utilizando sua conta Twitter. Sair / Alterar )

Foto do Facebook

Você está comentando utilizando sua conta Facebook. Sair / Alterar )

Foto do Google+

Você está comentando utilizando sua conta Google+. Sair / Alterar )

Conectando a %s

%d blogueiros gostam disto: