Servizio dati WCF OData con NHIBERNATE e Logica aziendale aziendale

Question

Vorrei prima scusarmi per la lunghezza dell'intero argomento. Sarà abbastanza lungo, ma desidero essere sicuro che il messaggio arrivi chiaramente senza errori.

Qui in azienda, abbiamo una WebApplication ASP.NET esistente. Scritto in C# ASP.NET su .NET Framework 3.5 SP1. Qualche tempo fa è stata sviluppata un'API iniziale per questa applicazione Web utilizzando WCF e SOAP per consentire alle parti esterne di comunicare con l'applicazione senza fare affidamento sui browser.

Questa API è sopravvissuta per un po 'di tempo, ma alla fine la richiesta è arrivata a creare una nuova API che è stata riposata e basandosi su nuove tecnologie. Mi è stato assegnato questo incarico e ho creato l'API iniziale utilizzando il framework Microsoft MVC 2, in esecuzione all'interno della nostra applicazione WebNET ASP.NET. Inizialmente questo ci è voluto un po 'di tempo per farlo funzionare correttamente, ma al momento siamo in grado di effettuare chiamate di riposo sull'applicazione per ricevere XML che descrive in dettaglio le nostre risorse.

Ho partecipato a un webcamp Microsoft e sono stato immediatamente venduto dal concetto Odata. Era molto simile a quello che stiamo facendo, ma questo era un protocollo supportato da più giocatori invece della nostra implementazione. Attualmente sto lavorando a un POC (prova del concetto) per ricreare l'API che ho sviluppato utilizzando il protocollo OData e la tecnologia WCF DataService.

Dopo aver cercato su Internet per far funzionare Nhibernate 2 con i servizi dati, sono riuscito a creare una versione readonly dell'API che ci consente di leggere le entità dal livello aziendale interno mappando le richieste di query in arrivo al nostro livello aziendale. Tuttavia, desideriamo avere un'API funzionale che consenta anche la creazione di entità utilizzando il protocollo OData. Quindi ora sono un po 'bloccato su come procedere. Ho letto il seguente articolo: http://weblogs.asp.net/cibrax/default.aspx?pageindex=3

L'articolo di cui sopra spiega come mappare un servizio dati personalizzato sul livello NHibernate. L'ho usato come base per continuare, ma ho il "problema" che non voglio mappare le mie richieste direttamente al database usando NHibernate, ma desidero mapparle al nostro livello aziendale (una DLL separata ) che esegue un grande lotto di controlli, vincoli e aggiornamenti basati su accessi, privilegi e trigger.

Quindi cosa voglio chiedere, ad esempio creo la mia classe NHibernateContext come nell'articolo sopra, ma invece faccio affidamento sul nostro livello aziendale anziché sulle sessioni di nhibernate, potrebbe funzionare? Probabilmente dovrei fare affidamento sulla riflessione molto per capire il tipo di oggetto con cui sto lavorando in fase di esecuzione e chiamare le classi di business corrette per eseguire gli aggiornamenti e le eliminazioni.

Per dimostrare con un'immagine SMAL ASCII:

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

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

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

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

Quindi, funzionerebbe o le prestazioni lo renderebbero inutile? O mi manca solo la palla qui? L'idea è che desidero riutilizzare qualunque logica sia memorizzata nel livello Bul & Dal dal DataService Odata WCF.

Stavo pensando di creare nuove classi che ereditano dalle classi EntityModel nello spazio dei nomi dei servizi. Servizi e creano un nuovo oggetto DataService che segna tutte le chiamate ai livelli Bul & Dal & API. Tuttavia, non sono sicuro di dove/chi intercettare le richieste di creazione ed eliminazione delle risorse.

Spero che sia un po 'chiaro cosa sto cercando di spiegare e spero che qualcuno possa aiutarmi su questo.

Answer 1

Il diavolo è nei dettagli, ma sembra che il design che stai proponendo dovrebbe funzionare.

La classe DataService è dove si possono definire i diritti di accesso applicabili a tutti, le impostazioni di configurazione e le operazioni personalizzate. In questo scenario, penso che invece ti concentrerai maggiormente sul contesto dei dati (la "T" in DataService).

Per il contesto, ci sono davvero due percorsi di intesa: letture e scritture. Le letture avvengono attraverso i punti di ingresso iqueryable. Scrivere un fornitore LINQ è un buon pezzo di lavoro, ma Nhibernate lo supporta già, anche se restituirebbe ciò che immagino stiamo chiamando entità Dal. È possibile utilizzare intercettori di query per eseguire i controlli di accesso qui se puoi esprimere quelli in termini che il database avrebbe capito.

Il percorso di aggiornamento è da quello che ho capito dove stai cercando di eseguire più logica aziendale (hai menzionato la convalida, gli aggiornamenti extra, ecc.). Per fare ciò, ti consigliamo di concentrarti sull'implementazione iupdatable (IdataserviceUpdateProvider se stai utilizzando l'ultima versione). Qui puoi usare qualsiasi oggetto che desideri: potrebbero essere oggetti Dal o oggetti aziendali. Puoi fare tutto nel Dal e quindi eseguire la convalida su SaveChanges () o fare tutto sugli oggetti aziendali se convalidano mentre vanno.

Ci sono due posti in cui potresti "saltare" da un tipo di oggetti all'altro. Uno è nell'API getResource (), in cui si ottiene una durata, presumibilmente in termini di entità dal. L'altro è in ResolveResource (), in cui il runtime chiede un oggetto per serializzare, proprio come otterrebbe da un iqueryable, quindi presumibilmente è anche un'entità dal.

Spero che questo aiuti: fare un accesso uniforme su API non uniformi può essere difficile, ma spesso ne vale la pena!