.NET For Your Information

Un blog más sobre tecnología .NET

Entity Framework para Aplicaciones Empresariales

with 7 comments


Tal y como comenté en el post de Introducción a Programación en capas con Visual Studio 2008, el Entity Framework (EF) nos provee una nueva forma de generar nuestros métodos de acceso a datos CRUD (create, read, update y delete), además de proveer todo un diagrama de clases a partir del cual se generarán todos los objetos dependiendo de las entidades y relaciones que formen nuestra base de datos. El EF es el ORM (Object-relational mapping) de .NET Framework a partir de su versión 3.5, siendo su principal competidor NHibernate, el cual nace de Hibernate, el ORM de Java por naturaleza.

Entity Framework

Sin duda, la conceptualización y objetivo del EF proporciona una serie de ventajas en el desarrollo de SW:

  • Minimiza la cantidad de código a desarrollar en aplicaciones orientadas a data. Genera los objetos de negocio, y métodos de acceso a datos, es decir, gran parte de lo que generalmente requerimos para el desarrollo de una aplicación.
  • Independiente del motor de base de datos. A diferencia de LINQ, el EF no trabaja exclusivamente con SQL Server, sino también con el resto de sistemas manejadores de bases de datos como Oracle, MySQL, PostgreSQL, etc.

En este blog podrán encontrar una serie de posts que les ayudará a empezar a desarrollar aplicaciones n-layer con Entity Framework. En lo único que discrepo con su autor es que el modelo “.edmx” debería generarse en la capa de Reglas de Negocios, dado que es aquí donde, por definición, deben estar todos los objetos de negocio.

Cabe destacar, que el EF tiene su lenguaje propio que permite mayor interacción y flexibilidad en las operaciones de acceso a datos. Dicho lenguaje es el Entity SQL.

Sin embargo, cuando se trata de desarrollos para Aplicaciones Empresariales, donde la base de datos contenga aproximadamente 100 tablas o más, y que exista un promedio de dos relaciones por tabla, el funcionamiento del Entity Framework está lejos de ser el esperado. El propio equipo de ADO.NET, quienes desarrollaron el EF, ha reconocido los problemas mediante este post en su blog. De manera resumida, enumeraré algunos inconvenientes:

  • Excesivo tiempo de carga de la metadata que forma el EF.
  • Saturación del modelo en el diseñador del EF, lo que conlleva a su ilegibilidad.
  • Mal comportamiento del IntelliSense provisto por Visual Studio, debido al gran número de clases y atributos generados.

A pesar de que, en un segundo post, el equipo de ADO.NET ha intentado brindar soluciones a estas fallas, éstas no han convencido a sus usuarios, pues lo que intenta hacer es adaptar al desarrollador a la forma de usabilidad del EF, condicionándolo, cuando es el EF quien debe cumplir las funciones para las cuales fue desarrollado. A continuación, un resumen de estas posibles soluciones:

  • Subdividir el modelo de clases en modelos más pequeños, haciendo reutilización de tipos para poder completar funcionalidad. Esto implicaría “meterle a mano” al código generado automáticamente, con todas las posibles consecuencias que esto pueda acarrear.
  • Seleccionar las tablas que estén desconectadas del modelo, es decir, sin relaciones o foreign keys. Evidentemente, esto representaría un porcentaje muy bajo en relación a todo el modelo ER.

Además de mis críticas a las soluciones propuestas, aquí podrán encontrar otros argumentos que sustentan la crítica constructiva al uso del Entity Framework en aplicaciones con grandes modelos de base de datos.

Por último, la buena noticia es que Microsoft, a través de su equipo de ADO.NET, ha seguido y seguirá invirtiendo recursos para la evolución y mejora del Entity Framework, los cuales se podrán empezar a percibir a partir del .NET Framework 4.0 y Visual Studio 2010.

Como siempre, bienvenidos sean sus comentarios.

Anuncios

Written by Alejandro Afonso Spinola

31 julio 2009 a 11:17 AM

7 comentarios

Subscribe to comments with RSS.

  1. seria interesante ver un post comparando Nhibernate con EF. Saludos!

    @lici@

    31 julio 2009 at 4:06 PM

    • Buena sugerencia. Lo consideraré para un futuro post.

      Gracias por tu comentario @lici@. Saludos

      Alejandro Afonso Spinola

      31 julio 2009 at 4:12 PM

  2. Muy bueno el post! Ya me puse al dia con los contras de esta tecnologia para aplicaciones grandes..

    Las soluciones hasta ahora no son para nada convincentes!!

    Saludos

    Ana Mora

    3 agosto 2009 at 5:04 PM

  3. Ahora que estuve leyendo mas sobre este tema, tengo una pregunta para ti. Cuando dices que “el modelo “.edmx” debería generarse en la capa de Reglas de Negocios” entonces cual seria tu capa de acceso a datos?

    @lici@

    22 septiembre 2009 at 11:10 AM

  4. Buenas,

    ¿Cómo se implementan / mapean las relaciones *..* en EF Si queremos evitar entidades intermedias?

    Saludos

    Javi

    2 diciembre 2009 at 10:19 AM

    • Excelente pregunta Javi. Yo creo que la única forma de hacerlo es que, una vez mapeado el modelo de tu BD, te dispongas a modificar las clases generadas por el EF en el modelo lógico, aunque esto te pueda traer errores colaterales como consecuencia de estos cambios. Pero, la verdad, es que nunca lo he hecho. Suerte con eso.

      Alejandro Afonso Spinola

      23 diciembre 2009 at 5:47 PM

  5. the data reader is incompatible with specified ‘ColegioModel.Pais’. A menber of the type, ‘codigo_pais’, does not have a corresponding column in the data reader with the same name ”

    hola amigo, muy bueno el blog.
    Tengo unas consultas si me las pudieras aclarar (trabajo con c# 2010 y sql2005):
    1.- Como puedo enlazar mi StoreProcedure a Entity Framework 4. he visto ejemplos x ahi pero me salta una excepcion te paso
    “the data reader is incompatible with specified ‘ColegioModel.Pais’. A menber of the type, ‘codigo_pais’, does not have a corresponding column in the data reader with the same name ”

    mi storeprocedure:

    set ANSI_NULLS ON
    set QUOTED_IDENTIFIER ON
    GO
    ALTER PROCEDURE [dbo].[sp_InsertPais]
    @nombre_pais varchar(100),
    @codigo_pais varchar(13) = null
    /*@codigoOutput varchar(13) output*/
    AS
    BEGIN
    SET NOCOUNT ON;
    BEGIN TRAN InsertPais
    BEGIN TRY
    begin
    declare @codigoNuevo varchar(13)
    begin
    SELECT @codigoNuevo = codigo_pais FROM dbColegio.dbo.Pais where indicefila_pais =(select max(indicefila_pais)from dbColegio.dbo.Pais)
    INSERT INTO dbo.Pais (codigo_pais,nombre_pais)
    values(dbo.f_GeneraCodigo(@codigoNuevo,’PAIS’),@nombre_pais)
    commit tran InsertPais
    select dbo.f_GeneraCodigo(@codigoNuevo,’PAIS’) as NewCodigo
    /*SET @codigoOutput = dbo.f_GeneraCodigo(@codigoNuevo,’PAIS’)*/
    END
    end
    END TRY
    BEGIN CATCH
    rollback tran InsertPais
    END CATCH
    END

    Mi codigo en C#:
    _CE.sp_InsertPais(txtNombre.Text, txtCodigo.Text);
    MessageBox.Show(“El registro ha sido insertado”);

    Mi Tabla
    Pais {codigo_pais varchar(13), nombre_pais varchar(100), indicefila int}

    2. Caso parecido a otro procedimiento q tengo q es de eliminar. que me lanza la misma excepcion
    He inortado mis procedimientos al MODEL
    Amigo una ayuda

    Alx

    14 julio 2010 at 4:03 PM


Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s

A %d blogueros les gusta esto: