Si hay algo que me gusta de trabajar con .NET es que el ecosistema no se detiene. Hace unos a\u00f1os, cuando arranqu\u00e9 a usar Entity Framework, la discusi\u00f3n era \u00ab\u00bfEF o Dapper?\u00bb. Hoy esa discusi\u00f3n todav\u00eda existe, pero EF Core evolucion\u00f3 tanto que la balanza se inclin\u00f3 bastante. En este art\u00edculo repaso todas las novedades que llegaron desde .NET 8 hasta .NET 10, con ejemplos concretos y el contexto necesario para entender por qu\u00e9 cada feature importa.<\/p>\n\n\n\n
La versi\u00f3n 8 fue la que me hizo replantear varios patrones que ven\u00eda usando desde hace tiempo. Especialmente los Tipos Complejos<\/strong>, que resolvieron algo que siempre me molest\u00f3 de las Owned Entities.<\/p>\n\n\n\n Cuando modelamos Value Objects<\/strong> en DDD, la l\u00f3gica indica que un objeto como En producci\u00f3n esto se traduce en columnas como Otro punto de dolor hist\u00f3rico: guardar una lista de strings o enteros. La soluci\u00f3n cl\u00e1sica era crear una tabla auxiliar o serializar a mano. EF Core 8 lo resuelve nativamente: en SQL Server<\/strong> serializa a JSON autom\u00e1ticamente, en PostgreSQL<\/strong> usa tipos de array nativos.<\/p>\n\n\n\n La primera vez que vi esto funcionar en un query real me sorprendi\u00f3. EF genera el Cuando necesit\u00e1s ejecutar SQL crudo que retorna un escalar o un DTO que no est\u00e1 en tu Lo que m\u00e1s me gusta es que pod\u00e9s componer LINQ encima de este resultado, combinando la potencia del SQL manual con las ventajas del query pipeline de EF.<\/p>\n\n\n\n Con .NET 9, el foco se desplaz\u00f3 hacia rendimiento extremo e inteligencia artificial. Dos temas que, honestamente, no esperaba ver tan r\u00e1pido en el ORM.<\/p>\n\n\n\n Si est\u00e1s construyendo aplicaciones con IA generativa, tarde o temprano necesit\u00e1s almacenar y consultar embeddings<\/strong>. EF Core 9 introduce soporte de primera clase para esto en SQL Server, PostgreSQL (con pgvector) y Cosmos DB. Esto es clave para patrones como RAG (Retrieval Augmented Generation)<\/strong>.<\/p>\n\n\n\n En un proyecto donde implement\u00e9 un chatbot sobre documentaci\u00f3n interna, esto redujo el tiempo de integraci\u00f3n a la mitad. Antes hab\u00eda que saltar a SDKs separados; ahora EF Core maneja el acceso al store vectorial junto con el resto de la l\u00f3gica de datos.<\/p>\n\n\n\n EF Core 9 habilita compatibilidad con compilaci\u00f3n Native AOT<\/strong>, lo que significa arranques de aplicaci\u00f3n dr\u00e1sticamente m\u00e1s r\u00e1pidos y menor consumo de memoria. En microservicios y funciones serverless esto no es un detalle: es la diferencia entre ser viable o no. El modelo compilado pre-genera el mapeo en tiempo de build, eliminando la reflexi\u00f3n en runtime.<\/p>\n\n\n\n Una sola query SQL de .NET 10 se lanz\u00f3 en noviembre de 2025 y la versi\u00f3n de EF Core que lo acompa\u00f1a termin\u00f3 de pulir varias aristas que la comunidad ven\u00eda pidiendo. Algunas son peque\u00f1as pero hacen una diferencia real en el d\u00eda a d\u00eda.<\/p>\n\n\n\n \u00bfCu\u00e1ntas veces escribiste un Mucho m\u00e1s legible. La intenci\u00f3n queda clara en el c\u00f3digo sin tener que descifrar la cascada de lambdas.<\/p>\n\n\n\n Las actualizaciones masivas ahora permiten lambdas regulares en lugar de \u00e1rboles de expresi\u00f3n estrictos. Esto permite agrupar setters en bloques m\u00e1s limpios, especialmente cuando actualiz\u00e1s m\u00faltiples propiedades a la vez.<\/p>\n\n\n\n Combinando lo mejor de dos mundos: los Complex Types de EF8 ahora pueden mapearse directamente como documentos JSON en una sola columna, con capacidad de consulta LINQ nativa dentro de ese JSON.<\/p>\n\n\n\n Los global query filters (soft delete, multitenancy) son muy \u00fatiles, pero el problema siempre fue que para ignorar uno ten\u00edas que ignorarlos todos. EF Core 10 le pone nombre a cada filtro, permiti\u00e9ndote desactivar solo el que necesit\u00e1s.<\/p>\n\n\n\n En aplicaciones multitenant con soft delete, esto es oro puro. Ya no hay que elegir entre ver los registros borrados o perder el filtro de tenant.<\/p>\n\n\n\n Para los que trabajan con Cosmos DB y motores de b\u00fasqueda basados en IA, EF Core 10 introduce soporte nativo para Full-Text Search<\/strong> y Hybrid Search<\/strong>. Esta \u00faltima combina similitud vectorial con b\u00fasqueda de palabras clave usando Reciprocal Rank Fusion<\/em>, obteniendo lo mejor de ambos enfoques en una sola query.<\/p>\n\n\n\n Mirando el camino recorrido de .NET 8 a .NET 10, la evoluci\u00f3n es clara:<\/p>\n\n\n\n Si tu proyecto a\u00fan corre en EF Core 6 o 7, te recomiendo migrar. No solo por las features nuevas, sino porque el rendimiento en operaciones masivas mejor\u00f3 notablemente. Personalmente, lo que m\u00e1s uso en el d\u00eda a d\u00eda son los \u00bfTen\u00e9s dudas sobre alguna feature espec\u00edfica o quer\u00e9s ver un caso de uso m\u00e1s complejo? Dejalo en los comentarios.<\/p>\n","protected":false},"excerpt":{"rendered":" Recorro todas las novedades de Entity Framework Core desde .NET 8 hasta .NET 10: Complex Types, colecciones primitivas, b\u00fasqueda vectorial, Native AOT, LeftJoin nativo, Named Query Filters y Hybrid Search. Con ejemplos de c\u00f3digo reales y experiencias de proyectos propios.<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_jetpack_memberships_contains_paid_content":false,"footnotes":"","jetpack_publicize_message":"","jetpack_publicize_feature_enabled":true,"jetpack_social_post_already_shared":true,"jetpack_social_options":{"image_generator_settings":{"template":"highway","default_image_id":0,"font":"","enabled":false},"version":2}},"categories":[1,202],"tags":[348,346,347,304,350,344,185,187,351,345,349],"class_list":["post-1292","post","type-post","status-publish","format-standard","hentry","category-blog","category-dotnet","tag-net-10","tag-net-8","tag-net-9","tag-aot","tag-ddd","tag-ef-core","tag-entityframework","tag-linq","tag-native-aot","tag-orm","tag-vector-search"],"yoast_head":"\n1. Tipos Complejos (Complex Types)<\/h3>\n\n\n\n
Direcci\u00f3n<\/code> no tiene identidad propia: se define por sus atributos. Antes de EF8, si quer\u00edas mapear esto usabas Owned Entities<\/strong>, que internamente requer\u00edan una clave primaria oculta y te generaban joins innecesarios. Con los Complex Types<\/strong> en EF Core 8, las propiedades del objeto se mapean directamente como columnas en la tabla del padre. Sin clave, sin tabla aparte, sin overhead.<\/p>\n\n\n\n[ComplexType]\npublic class Direccion\n{\n public string Calle { get; set; }\n public string Ciudad { get; set; }\n}\n\npublic class Cliente\n{\n public int Id { get; set; }\n public string Nombre { get; set; }\n \n \/\/ Se mapear\u00e1 como columnas Calle y Ciudad en la tabla Clientes\n public required Direccion DireccionResidencia { get; set; } \n}<\/code><\/pre>\n\n\n\nDireccionResidencia_Calle<\/code> y DireccionResidencia_Ciudad<\/code> directamente en la tabla Clientes<\/code>. Mucho m\u00e1s limpio y sin el overhead de las relaciones.<\/p>\n\n\n\n2. Colecciones de Tipos Primitivos<\/h3>\n\n\n\n
public class Producto\n{\n public int Id { get; set; }\n public string Nombre { get; set; }\n public List<string> Etiquetas { get; set; } = new();\n}\n\n\/\/ EF Core traduce esto a funciones JSON en SQL Server\nvar productos = context.Productos\n .Where(p => p.Etiquetas.Contains(\"Urgente\"))\n .ToList();<\/code><\/pre>\n\n\n\nJSON_VALUE<\/code> correspondiente en SQL Server y la consulta funciona sin traer entidades a memoria.<\/p>\n\n\n\n3. Consultas SQL Nativas para Tipos No Mapeados (SqlQuery)<\/h3>\n\n\n\n
DbContext<\/code>, antes ten\u00edas que recurrir a ADO.NET o trucos con FromSqlRaw<\/code>. Con SqlQuery<T><\/code> ya no.<\/p>\n\n\n\nvar salarios = await context.Database\n .SqlQuery<decimal>($\"SELECT AVG(Salario) AS Value FROM Empleados\")\n .ToListAsync();<\/code><\/pre>\n\n\n\nNovedades en EF Core 9 (.NET 9)<\/h2>\n\n\n\n
4. B\u00fasqueda Vectorial (Vector Search)<\/h3>\n\n\n\n
public class Documento\n{\n public int Id { get; set; }\n public string Contenido { get; set; }\n public ReadOnlyMemory<float> Embedding { get; set; }\n}\n\nReadOnlyMemory<float> vectorBusqueda = ObtenerVector(\"\u00bfc\u00f3mo configuro autenticaci\u00f3n?\");\n\nvar docs = await context.Documentos\n .OrderBy(d => EF.Functions.VectorDistance(d.Embedding, vectorBusqueda)) \n .Take(5)\n .ToListAsync();<\/code><\/pre>\n\n\n\n5. Optimizaciones de Rendimiento y Native AOT<\/h3>\n\n\n\n
6. Mejoras en Actualizaciones y Borrados Masivos<\/h3>\n\n\n\n
ExecuteUpdate<\/code> y ExecuteDelete<\/code> se introdujeron en EF7, pero en EF9 se potenciaron para soportar actualizaciones de Complex Types y traducir expresiones LINQ m\u00e1s avanzadas. Lo importante: siguen sin traer entidades a memoria.<\/p>\n\n\n\nawait context.Productos\n .Where(p => p.Categoria == \"Herramientas\")\n .ExecuteUpdateAsync(s => s.SetProperty(p => p.Precio, p => p.Precio * 1.10m));<\/code><\/pre>\n\n\n\nUPDATE<\/code>. Sin SaveChanges<\/code>, sin tracking, sin roundtrips innecesarios.<\/p>\n\n\n\nNovedades en EF Core 10 (.NET 10)<\/h2>\n\n\n\n
7. Operadores Expl\u00edcitos LeftJoin y RightJoin<\/h3>\n\n\n\n
GroupJoin<\/code> + SelectMany<\/code> + DefaultIfEmpty<\/code> solo para hacer un LEFT JOIN? Demasiadas. EF Core 10 lo resuelve con operadores directos.<\/p>\n\n\n\nvar clientesConYsinPedidos = await context.Clientes\n .LeftJoin(\n context.Pedidos,\n c => c.Id,\n p => p.ClienteId,\n (c, p) => new { c.Nombre, PedidoId = p?.Id }\n ).ToListAsync();<\/code><\/pre>\n\n\n\n8. Flexibilidad en ExecuteUpdateAsync (Lambdas)<\/h3>\n\n\n\n
await context.Productos.Where(p => p.Stock < 10)\n .ExecuteUpdateAsync(s => {\n s.SetProperty(p => p.RequiereReabastecimiento, true);\n s.SetProperty(p => p.FechaAviso, DateTime.UtcNow);\n });<\/code><\/pre>\n\n\n\n9. Columnas JSON Avanzadas para Tipos Complejos<\/h3>\n\n\n\n
modelBuilder.Entity<Usuario>()\n .ComplexProperty(u => u.Preferencias, p => p.ToJson());\n\n\/\/ Consulta dentro del JSON sin traer todo a memoria\nvar usuarios = await context.Usuarios\n .Where(u => u.Preferencias.Tema == \"Dark\")\n .ToListAsync();<\/code><\/pre>\n\n\n\n10. Filtros de Consulta Nombrados (Named Query Filters)<\/h3>\n\n\n\n
modelBuilder.Entity<Blog>().HasQueryFilter(\"FiltroBorrados\", b => !b.EstaBorrado);\n\n\/\/ Solo ignoro el filtro de borrados, el de tenant sigue activo\nvar blogs = await context.Blogs\n .IgnoreQueryFilter(\"FiltroBorrados\")\n .ToListAsync();<\/code><\/pre>\n\n\n\n11. B\u00fasqueda H\u00edbrida y Full-Text (Cosmos DB)<\/h3>\n\n\n\n
var resultados = await context.Documentos\n .OrderBy(x => EF.Functions.VectorDistance(x.Embedding, vectorUsuario)) \n .ThenBy(x => EF.Functions.FullTextRank(x.Contenido, \"t\u00e9rmino exacto\")) \n .Take(5)\n .ToListAsync();<\/code><\/pre>\n\n\n\nResumen: La Evoluci\u00f3n de EF Core en Tres Versiones<\/h2>\n\n\n\n
\n
ExecuteUpdate\/ExecuteDelete<\/code> para evitar cargar entidades innecesariamente, y los Complex Types para modelar Value Objects sin el overhead de las Owned Entities.<\/p>\n\n\n\n