.net linq nhibernate orm soa

ORM y SOA en el mundo.NET



linq nhibernate (7)

LLBLGen Pro tiene seguimiento de cambios dentro de las entidades. Esto significa que puede buscar un gráfico de la base de datos utilizando rutas de captación previa (por lo tanto, una consulta por nodo de gráfico) y serializarlo a través del cable al cliente, cambiarlo allí, enviarlo y guardar directamente el gráfico ya que todo el seguimiento de cambios está dentro las entidades (y se serializa dentro del XML como elementos personalizados compactos).

Descargo de responsabilidad: soy el desarrollador principal de llblgen pro.

Desde mi experiencia, los principales marcos ORM para .NET ( NHibernate , LinqToSql , Entity Framework ) funcionan mejor cuando realizan un seguimiento de los objetos cargados. Esto funciona bien para aplicaciones simples de cliente-servidor, pero cuando se usa arquitectura de tres o más niveles con servicios web en una arquitectura orientada a servicios, esto no es posible. Eventualmente, al escribir una gran cantidad de código para hacer el seguimiento usted mismo, se podría hacer, pero ¿no se supone que ORM simplifica el acceso a la base de datos?

¿Es buena la idea de usar ORM en arquitectura orientada a servicios?

El marco ORM le ayudará solo cuando habla directamente con la base de datos. Incluso en arquitecturas orientadas a servicios, los ORM solo pueden ayudar a reducir la carga al programar esa capa final. Necesitará otras técnicas, como WCF , para manejar la parte del servicio. Todavía no conozco a nadie que integre ORM y servicios, pero debería ser bastante directo anotar las mismas clases que entidades y DataContract .

Sugeriría humildemente que deje de tratar de usar objetos distribuidos como un patrón arquitectónico. Simplemente no es tan efectivo como una arquitectura de mensajería o un estilo RESTful.

Si no le gusta la sobrecarga de la transferencia de datos dentro y fuera de los mensajes, le sugiero que mire REST. Sin embargo, no REST en la forma en que lo hace ADO.NET Data Services, es decir, solo objetos distribuidos a través de HTTP.

REST se trata más de exponer una UI fea (pero legible por máquina) en el servidor y usar el cliente para que se vea bonita. En REST no hay conocimiento de las entidades de dominio en el cliente, por lo que no es necesario que las envíe a través del cable.

SignumFramework también tiene un seguimiento dentro de las entidades. También tiene un proveedor completo de Linq, pero solo puede trabajar con nuevas bases de datos (genera el esquema de sus entidades c #, no el opuesto).

Seguimiento de cambios: http://www.signumframework.com/ChangeTracking.ashx

Descargo de responsabilidad: soy el desarrollador principal de Signum Framework :)

Depende de lo que quieras decir con ''SOA''. La exposición de objetos de dominio en contratos de servicio rara vez es un buen diseño de servicio: expone los detalles internos de implementación, hay una mayor probabilidad de cambio en un contrato publicado, y el control de versiones se vuelve muy difícil.

Si crea documentos de mensajes personalizados (por ejemplo, WCF DataContracts) para sus endpoints de servicio, es relativamente fácil usar ORM para implementar el servicio. Normalmente, volvería a cargar el objeto de dominio desde la base de datos y mapear las propiedades modificadas (o llamar a un método), y luego conservar los cambios.

Si su servicio es principalmente métodos CRUD, su mensaje personalizado será efectivamente un DTO. Tendrá que administrar manualmente la concurrencia optimista y la asignación de objetos de dominio.

Actualización: Esta es una respuesta anterior, por lo que me gustaría señalar que EF4 también incluye el seguimiento de cambios en las entidades . Sigo manteniendo que este es un diseño de contrato de servicio deficiente, pero si buscas un marco de aplicaciones distribuidas, probablemente sea una buena opción.

Puedes usar memcached como un caché de segundo nivel con NHibernate. ¿Eso es lo que querías decir con ''Keeping track''?