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.

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