Servicio de datos WCF de OData con NHibernate y lógica de negocios corporativos

Question

Permítanme primero disculparme por la duración de todo el tema. Será bastante largo, pero deseo estar seguro de que el mensaje llegue claramente sin errores.

Aquí en la empresa, tenemos una aplicación web ASP.NET existente. Escrito en C# ASP.NET en .NET Framework 3.5 SP1. Hace algún tiempo, se desarrolló una API inicial para esta aplicación web utilizando WCF y SOAP para permitir que las partes externas se comuniquen con la aplicación sin depender de los navegadores.

Esta API sobrevivió durante un tiempo, pero finalmente la solicitud llegó para crear una API nueva que era RESTfull y confiaba en nuevas tecnologías. Me asignaron esta tarea y creé la API inicial utilizando el Microsoft MVC 2 Framework, que se ejecuta dentro de nuestra aplicación web ASP.NET. Inicialmente, esto tardó un tiempo en apagarse para que funcionara correctamente, pero por el momento podemos realizar llamadas REST en la aplicación para recibir XML detallando nuestros recursos.

He asistido a un Microsoft WebCamp, y el concepto OData me vendió inmediatamente. Fue muy similar a lo que estamos haciendo, pero este era un protocolo respaldado por más jugadores en lugar de nuestra propia implementación. Actualmente estoy trabajando en un PoC (Prueba de concepto) para recrear la API que desarrollé utilizando el protocolo OData y la tecnología WCF DataService.

Después de buscar en Internet para obtener NHibernate 2 para trabajar con los servicios de datos, tuve éxito en la creación de una versión de ReadOnly de la API que nos permite leer las entidades de la capa de negocios interna mapeando las solicitudes de consulta entrantes a nuestro Capa empresarial Sin embargo, deseamos tener una API funcional que también permita la creación de entidades utilizando el protocolo OData. Así que ahora estoy un poco atascado sobre cómo proceder. He estado leyendo el siguiente artículo: http://weblogs.asp.net/cibrax/default.aspx?PageIndex=3

El artículo anterior explica muy bien cómo mapear un DataService personalizado a la capa NHibernate. Lo he usado como base para continuar, pero tengo el "problema" de que no quiero asignar mis solicitudes directamente a la base de datos usando NHibernate, pero deseo asignarlas a nuestra capa Business (una DLL separada).) que realiza un gran lote de verificaciones, restricciones y actualizaciones basadas en derechos de acceso, privilegios y disparadores.

Entonces, lo que quiero preguntar es, por ejemplo, crear mi propia clase NhibernateContext como en el artículo anterior, pero en cambio confiar en nuestra Business Layer en lugar de las sesiones de NHibernate, ¿podría funcionar? Probablemente tendré que confiar mucho en la reflexión para averiguar el tipo de objeto con el que estoy trabajando en tiempo de ejecución y llamar a las clases de negocios correctas para realizar las actualizaciones y las eliminaciones.

Para demostrar con una imagen ASCII Smal:

       *-----------------* 
           * Database  * 
           *-----------------* 

           *------------------------* 
           * DAL(Data Access Layer) * 
           *------------------------* 

           *------------------------* 
           * BUL (Bussiness Layer) * 
           *------------------------* 
           *---------------* *-------------------* 
           * My OData stuff* * Internal API  * 
           *---------------* *-------------------* 

               *------------------* 
               * Web Application * 
               *------------------* 

Por lo tanto, sería este trabajo, o sería el rendimiento que sea inútil? ¿O solo me falta el balón aquí? La idea es que deseo reutilizar cualquier lógica almacenada en la capa DAL BUL & del servicio de datos WCF de OData.

Estaba pensando en la creación de nuevas clases que heredan de las clases del espacio de nombres EntityModel Data.Services y crear un nuevo objeto DataService que marca todas las llamadas a las capas API BUL & & DAL. Sin embargo, no estoy seguro de dónde/quién para interceptar las solicitudes de creación y eliminación de recursos.

Espero que esté un poco claro lo que estoy tratando de explicar, y espero que alguien me pueda ayudar en esto.

Answer 1

El diablo está en los detalles, pero parece que el diseño que usted propone debería funcionar.

La clase DataService es donde puede definir los derechos de acceso aplicables a todos, configuraciones y operaciones personalizadas. En este escenario, creo que se centrará más en el contexto de los datos (la 'T' en DataService).

Por el contexto, hay realmente dos caminos interesantes: lecturas y escrituras. Las lecturas suceden a través de los puntos de entrada IQueryable. Escribir un proveedor LINQ es una buena parte del trabajo, pero NHibernate ya lo admite, aunque devolvería lo que imagino que estamos llamando entidades DAL. Puede usar interceptores de consultas para hacer verificaciones de acceso aquí si puede expresarlos en términos que la base de datos pueda entender.

La ruta de actualización es por lo que entiendo en donde está tratando de ejecutar más lógica de negocios (mencionó validación, actualizaciones adicionales, etc.). Para hacer esto, querrá enfocarse en la implementación IUpdatable (IDataServiceUpdateProvider si está usando la última versión). Aquí puede usar los objetos que desee: pueden ser objetos DAL u objetos comerciales. Puede hacer todo en DAL y luego ejecutar la validación en SaveChanges(), o hacer todo en objetos comerciales si validan sobre la marcha.

Hay dos lugares donde puede "saltar" de un tipo de objeto a otro. Uno está en la API GetResource(), donde obtienes un IQueryable, presumiblemente en términos de entidades DAL. El otro está en ResolveResource(), donde el tiempo de ejecución solicita que un objeto se serialice, tal como lo haría con un IQueryable, por lo que presumiblemente también es una entidad DAL.

Espero que esto ayude: hacer el acceso uniforme a través de API no uniformes puede ser difícil, ¡pero a menudo vale la pena!