Informática y Sistemas (β)

2009/08/27 - 27 agosto 2009

Consideraciones para plantear una arquitectura en n-capas con Visual Studio

Entity Framework

A partir de la versión de Visual Studio 2008 se incorporaron facilidades para implementar librerías de Linq y Edm (Entity Data Model) que forman parte del Framework 3.5, que en apariencia ofrecían un modelo más especializado para trabajar entidades. De hecho hasta presentan clases y espacios de nombres especializados en su manejo (Entity). Lo más natural parecería ser el trabajar en estos nuevos marcos, ya que las facilidades de generación y mantenimiento de entidades fuertemente tipadas estarían resueltos; sabiendo que lo más incómodo de trabajar por n-capas es el caer en la trampa de crear y mantener manualmente un sinnúmero de interminables clases o estructuras de datos, y los métodos para ir traduciéndolos a medida que se traspasan desde la base de datos hasta la capa de presentación; sobre todo si se manejan mensajes en vez de referencias de librerías.

Pues bien, Linq y Edm no son la panacea de la felicidad prometida. Lamentablemente están pensados básicamente para arquitecturas de aplicación de una capa, orientada fuertemente a objetos; donde la conexión o instancia de contexto de enlace a base de datos está permanentemente viva. De hecho, su lógica interna apunta más al trabajo de consultas inyectadas por sql dinámico, lo que no solo es ineficiente en bases de datos con mediano o gran peso, sino que además en el escenario desconectado de la arquitectura en capas quedan obsoletos o inútiles el 70% de sus métodos u objetos; mayormente dedicados a consultas directas dentro de un contexto instanciado. Y si aún así se desearan conservar estas entidades por la facilidad de generación, el enlace a controles y control de modificaciones o actualizaciones es sumamente complicado ya que la propiedad de estado interno de las entidades es de solo lectura, y se modifica a partir de su uso por el contexto, por lo que dichos objetos no son un apoyo o recurso reutilizable en modo desconectado.

Tratar de adaptar este y otros aspectos de conexión y manejo transaccional, lleva a complementar las entidades definiendo clases parciales o heredadas, con propiedades y métodos que de a poco los llevan a parecerse a los DataSet. Por lo tanto, la mejor herramienta por el momento para crear entidades fuertemente tipadas siguen siendo los DataSet; o si se quiere sufrir un poco más, pero aún el preferido por los amantes del acoplamiento por mensajes, clases seralizables basadas en propiedades con atributos xml.

(tiny)

Anuncios

1 comentario »

  1. […] n-tier architecture with Visual Studio Filed under: Development tips — Mario Mendez @ 8:14 pm Tags: DataSet, EDM, LinQ, n-tier, Visual Studio (original post) […]

    Pingback por n-tier architecture with Visual Studio « Computing and systems (β) — 2009/11/03 - 3 noviembre 2009 @ 22:14 | Responder


RSS feed for comments on this post. TrackBack URI

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

Crea un blog o un sitio web gratuitos con WordPress.com.

A %d blogueros les gusta esto: