Eligiendo un framework para base de datos

De regreso a los buenos viejos días, donde PHP y ASP clásico gobernaban el Internet, el código para conectar y manipular una base de datos estaba normalmente construido en el framework, en la forma de un conjunto de funciones y/o clases. Estas funciones/clases serían suficientes para la mayoría de los propositos, porque simplemente les proveerías comandos para la base de datos (frecuentemente en forma de consultas SQL) y ellos regresarían a ti con resultados, ya sea en forma de filas crudas de base de datos o un número de filas afectadas.

Hoy, esto es considerado un poco como vieja escuela, en su lugar, esperas usar algun tipo de framework que abstraiga mucho, o casi todo, de el SQL (o cualquer lenguaje que tu base de datos hable), permitiendote trabajar con objetos en lugar de filas de base de datos. Ejemplos de este tipo de frameworks incluyen LINQ para SQL y el Entity Framework de .NET, con la reciente existencia de una versión del framework .NET Core también (EF Core).

ORM - Object-Relation Mapping

El Entity Framework es un llamado ORM - un Object-Relation Mapper o Mapeador de Relación-Objeto. Esto hará la comunicación entre tu base de datos y tu código mucho más fácil, porque como puedes sabre, el framework .NET (y muchos otros lenguajes de programación) usa objetos mientras una base de datos relacional usa tablas, para representar la misma cosa. Un escenario común sería entonces tener una tabla "Movies" en tu base de datos, para representar una o varias películas, y una clase "Movie" en tu proyecto .NET, para representar cada película en la tabla "Movies".

Sin un ORM, tu serías responsable de la comunicación entra la tabla y el objeto: Cuando traes filas de la base de datos, tendrías manualmente que cargar los objetos Movie, y cuando insertas datos, tendrías que agregar todas las propiedades relevantes de objeto Movie para el comando SQL que luego insertaras en la tabla de la base de datos.

Puedes usar aún este enfoque de la vieja escuela, gracias a las clases de ADO .NET encontradas en el espacio de nombres System.Data.SqlClient. Eso te dará todo el control que puedas soñar, pero son algo tediosas de usar - no hay absolutamente mapeo entre tus objetos y las tablas de las bases de datos e incluso operaciones simples requieren varias líneas de código y el uso de varias clases como SqlConnection, SqlCommand, SqlDataReader, etc.

En otra mano, cuando usas un ORM, puedes hacer mucho con incluso una simple línea de código porque mucho del poder ha sido empaquetado en comandos cortos. No tienes que escribir nada de SQL - en vez de eso, le dices al framework que quieres lograr con un comando como Select(), y lo transformara en algo que el motor de base de datos entienda, por ejemplo SQL, y en cambio, recibirás objetos .NET listos para usarse.

La desventaja es la gran perdida de control: cuando llamas a estos simples comandos, el framework decide como son manejados mejor. Cuando tu base de datos empieza a crecer en tamaño y complejidad, puedes terminar viendo grandes problemas de rendimiento porque el ORM no entiende tus datos y/o intenciones lo suficiente para transformarlos en comandos que rindan suficiente. Otra desventaja es que puedes no enteder porque esta pasando eso, por todas esas abstracciones, tu no sabes que tabla de la base de datos es o como hablar con ella.

Eligiendo un ORM

En la mayoria de los tutoriales de ASP.NET, especialmente los relacionados a MVC, veras que el Entity Framework es usado. Este es la solución recomendada por Microsoft, pero no será la que usemos en este tutorial. Hay muchas razones para esto, como marque arriba, pero la mas importante es que particularmente no me gusta Entity Framework. Lo intente usar un par de veces, pero nunca estaba comodo con la perdida de control que pagaba por la facilidad de uso. Otra buena razón para hacer las cosas diferentes es enseñarte que hay alternativas y eso con la gran flexibilidad ´que tienes con el framework .NET, siempre es posible hacer las cosas diferente.

He elegido en su lugar un compromiso entre el muy abstracto Entity Framework y el codeo a mano casi todo con ADO.NET llamado Dapper y es frecuentemente referido como un Micro-ORM. Este abstrae las cosas más aburridas, mientras te permite aún tomar control total de como esta hecho todo.

Así que con Dapper, no tienes que mapear manualmente entre tablas y objetos, pero aun así escribir el SQL que trae los datos. También te permitirá obtener algo de conocimiento sobre la base de datos subyacente y como funciona, lo cual te beneficiará después, especialmente sí empiezas a trabajar en proyectos más complejos con gran cantidad de datos.

Otra cosa genial de Dapper es el hecho de que simplemente extiende de la interfaz IDbConnection, singificando que puedes usar las clases existentes para tratar con tu base de datos de elección (por ejemplo SqlConnection, que implementa IDbConnection) - en otras palabras, sí .NET soporta tu base de datos y tu base de datos soporta SQL, ¡puedes usar Dapper!

Resumen

Ahora hemos seleccionado un motor de base de datos (MS SQL Server) y un framework de base de datos/ORM (Dapper). Con eso en su lugar, necesitamos establecer e integrar todo, para que podamos empezar a construir nuestra aplicación web de TODO-list. Veremos mas en el siguiente artículo.