Entity Framework es el ORM (Object-Relational Mapper) de Microsoft, con versiones tanto para la plataforma .NET "tradicional" como para .NET Core.
Como vimos en el artículo del enlace anterior, en el que se explicaba con detalle qué es un ORM, este tipo de software puede funcionar de varias maneras diferentes a la hora de "mapear" las clases de nuestro programa orientado a objetos y las tablas en la base de datos.
Entity Framework no es una excepción, y nos ofrece diversas maneras de trabajar con los datos desde nuestros programas. Cada una tiene un enfoque diferente y es interesante para ciertos casos concretos, además de tener sus beneficios y problemas.
Vamos a dar un repaso rápido a los 3 modos de trabajo principales de Entity Framework para ver en qué consisten y sus ventajas e inconvenientes.
Nota: debes tener muy claras las diferencias entre EF6 y EF Core antes de seguir. También las diferencias y similitudes entre la plataforma .NET "tradicional" y .NET Core.
Es importante tener en cuenta que las capacidades de Entity Framework en .NET "tradicional" (EF6) y en .NET Core (EF Core) son completamente diferentes. Así, los tres modos de trabajo descritos a continuación están completamente soportados en EF6, pero EF Core solamente soporta "Code First" y muy poquito de "Database First". "Model First" en .NET Core ni está ni se le espera. A continuación lo detallaremos más.
Database First
En este modo se parte de una base de datos pre-existente con la que queremos trabajar. Es decir, tenemos la base de datos ya diseñada y probablemente con datos y lo que queremos es que EF se encargue de generar las clases necesarias y toda la "fontanería" interna para trabajar con ella.
Se suele utilizar si aprovechamos una base de datos existente y queremos crear una nueva aplicación sobre ésta. Por ejemplo, vamos a modernizar una aplicación antigua y queremos aprovechar todo lo que hay en la capa de datos, o si le añadimos una nueva API por encima a una aplicación que usa otra tecnología para el acceso a datos.
En este caso Entity Framework creará las entidades orientadas a objetos (las clases) de manera automática, y las actualizará en caso de que haya cambios en la base de datos subyacente. Para generar las entidades utiliza plantillas T4 (que son una mezcla de texto y lógica que permiten generar nuevos archivos). Si queremos una personalización especial para alguna entidad generada deberemos tocar las plantillas T4 o bien usar clases parciales.
Ventajas o beneficios de Database First
- El trabajo en Visual Studio es muy visual. El diseñador visual muy cuidado
- Son muy sencillas de implementar, pues casi todo va en automático y parten de la base de datos
- Si tienes costumbre de trabajar con bases de datos, llevando a cabo primero el diseño E-R, y te sientes menos cómodo con código C#, entonces estarás como en casa.
- Se lleva bien con proyectos de datos grandes, con muchas tablas, convenientemente repartidas en varios modelos.
- Es muy complicado que pierdas datos al hacer modificaciones en el modelo, ya que las harás en la base de datos, no en el código de la aplicación.
Problemas o inconvenientes de Database First
- El código resultante para los modelos tiene infinidad de código auto-generado sobre el que tenemos poco control y que puede acabar "pesando" mucho. Si hay algún problema te costará más ver de dónde te viene.
- Si necesitas personalizar las clases o su comportamiento debes extenderlas con clases parciales o bien tocando las plantillas T4. Dependiendo de lo que quieras hacer puedes acabar escribiendo bastante código, que probablemente es lo que querías evitar usando este modelo.
- Cada vez que haces cambios en la base de datos se debe regenerar el archivo EDMX que la representa, lo cual puede llevar bastante tiempo dependiendo de lo grande que sea. Si estás haciendo y probando muchos pequeños cambios puede llegar a desesperarte.
Database First solamente está soportado completamente en la plataforma .NET (EF6). En Entity Framework Core podemos generar las entidades y los contextos de datos utilizando una herramienta de línea de comandos, pero no disponemos de ningún diseñador ni nada que nos permita hacerlo de manea interactiva. Tampoco existen plantillas T4 para editar, ni archivos EDMX. La actual herramienta solo permite hacer la generación desde una base de datos inicial, pero si luego hay cambios sobre ésta no podremos incorporarlos al modelo. En la próxima versión 2.1 se supone que incorporarán esta posibilidad.
Model First
Este nombre puede despistarte, sobre todo si vienes del mundo MVC, en el que el "Modelo" de la "M" en su nombre, es código que escribes para modelar tus datos. En este caso se refiere a crear tu modelo de datos visualmente, usando el Diseñador de Modelos de Visual Studio. No tienes que escribir código alguno.
Describes visualmente el modelo de objetos que quieres crear, con las entidades, sus propiedades, relaciones entre ellas (que generan propiedades de navegación entre las entidades), etc... y luego Entity Framework se encarga de generar la base de datos subyacente o modificarla y también las entidades POCO (Plain Old C# Object, o sea, clases normales y corrientes de C#) que representan dicho modelo, usando plantillas T4.
Ventajas o beneficios de Model First
- El diseñador visual facilita enormemente el diseño del modelo de datos.
- Es un sistema interesante porque te evita tanto escribir código como definir la base de datos (aunque puedes generar el modelo inicial de una base de datos preexistente si quieres). Si no eres de las personas que disfrutan escribiendo código y mucho menos definiendo bases de datos, te ahorrará muchos desvelos.
- Es muy productivo en proyectos pequeños, pues te olvidas de definir clases y de tocar bases de datos. Es lo más parecido a la "magia" que te ofrece EF.
Problemas o inconvenientes de Model First
- Pierdes el control tanto de la base de datos como de las clases generadas. Se encarga de todo EF, lo cual es estupendo si no necesitas nada "especial", pero te quita control en otros casos.
- Si quieres extender las clases, como antes, debes tocar las plantillas T4 o definir clases parciales.
- Por defecto los cambios que hagas en el modelo no generan scripts SQL incrementales, sino completos. Esto quiere decir que si haces un cambio y regeneras la base de datos, se elimina la actual y se crea de nuevo. Esto puede significar que pierdas los datos que ya tuvieses en la misma, así que mucho cuidado.
Este modo de funcionamiento sólo está disponible en EF6, es decir, en la plataforma .NET "tradicional", pero no en .NET Core. Existen algunas herramientas de terceros que permiten gestionar el modelo de forma visual, tanto para EF6 como con EFCore (y otros ORM), pero no debemos confundir esto con Model First: se trata tan solo de una capa de gestión visual que por debajo trabaja con Code First (que veremos a continuación).
Code First
Si en Database First empezábamos por la base de datos generando EF todo lo demás, y en Model First estábamos en el "medio" definiendo el modelo para que EF generase tanto las clases como la base de datos... en Code First nos situamos en el otro extremo del espectro: definimos nuestras clases mediante código, y EF se encarga de generar la base de datos y todo lo necesario para encajar las clases en ellas.
Se trata de un enfoque muy orientado al programador. Es para gente a la que le gusta escribir código y tener control total sobre cómo se comportan sus clases. En este caso EF no genera código, ni necesita complejos y pesados archivos EDMX para mapear objetos a la base de datos, por lo que todo es más ágil.
El programador define su modelo usando clases normales (POCO). Relaciona unas con otras simplemente haciendo referencia entre ellas en propiedades. A mayores puede decorar algunas propiedades de estas clases de forma especial (las llamadas "Annotations", "Anotaciones" en inglés) si quiere indicar cosas concretas, como por ejemplo el nombre que quiere darle al campo correspondiente en la base de datos, y cosas así. Y puede implementar algunos métodos de la clase dbContext para indicar cómo mapear ciertas cosas con la base de datos.
Por lo demás solo es necesario usar una herramienta de "Migraciones" desde el gestor de paquetes de Visual Studio para generar la base de datos, que se ve como un mero sistema de almacenamiento sin ninguna lógica, la cual se implementa en el código de las clases que hemos creado.
Ventajas o beneficios de Code First
- Máximo control sobre el código de tu modelo de datos en C#, ya que son clases que construyes desde cero.
- Te ofrece control sobre las colecciones de objetos que quieres que se carguen de modo "perezoso" (es decir, a medida que se vayan necesitando).
- No tocas una base de datos ni con un palo. El código es el que manda y el "tooling" se encarga de generar la base de datos en función de tu código.
- La estructura de la base de datos es muy fácil de mantener bajo control de código (con Git o similar) ya que no se guarda en absoluto: se guarda el código de nuestras clases del modelo, y se genera la base de datos bajo demanda.
Problemas o inconvenientes de Code First
- Debes dominar bastante más EF que con los enfoques anteriores.
- Cualquier cosa que necesites persistir u obtener de tu base de datos la tienes que implementar en código C# y LINQ. La base de datos que se genera por detrás no la puedes tocar.
- Si tu base de datos es muy grande y con muchas tablas, la gestión de la base de datos se puede convertir en un pequeño dolor de muelas.
Este es el único modo verdaderamente soportado por EF Core. Por ello es el más utilizado y en el que más hincapié se debe hacer a la hora de aprender, ya que nos servirá tanto para EF6 como para la plataforma más moderna de Microsoft.
¿Cuál escoger?
Ahora que hemos repasado las opciones, conociendo en qué consisten y sus ventajas e inconvenientes... ¿Cuál sería la mejor opción?
Bueno, si lo tuyo es .NET Core te quedas sin opciones: deberás usar Code First, sí o sí.
En el caso de EF6 y .NET "tradicional", tienes acceso a todo, por lo que para elegir, como todo en la vida, dependerá de muchos factores.
Los más puristas prefieren el enfoque de Code First frente a los demás. Les da el máximo rendimiento y control y además desde el punto de vista de un programador "puro", la base de datos es solo un mal necesario y lo importante es nuestro código. Además podrás aplicar casi todo a EF Core.
Los que dominan y valoran las bondades de las bases de datos, por el contrario, suelen preferir alguno de los anteriores, especialmente el Database First.
Si tu proyecto es pequeño y no va a tener muchas tablas/entidades que manejar, Code First puede ser muy cómodo y ágil, con control total por tu parte. Si por el contrario hay muchas tablas y el proyecto de datos es grande, Database First puede ser una gran opción aunque algún "purista" se rasgue las vestiduras.
En caso de que no te gusten demasiado las bases de datos ni tampoco tener que escribir todo el código de "fontanería" a mano, el enfoque Model First es una buena opción para los más vagos (dicho sea desde el cariño), ya que te permite diseñar visualmente las entidades/datos que quieres manejar y se encarga automáticamente de todo lo demás: generar las clases del modelo y las tablas en la base de datos, mapeándolos entre sí de manera transparente.
¡Espero que te resulte de ayuda!