Come definire le giunture tra il livello del dominio e un database pieno di procedure memorizzate?

4

Abbiamo un database precedente pieno di stored procedure.

Queste stored procedure sono in qualche modo classificate CRUD ma dopo l'ispezione di alcune procedure, non sono "semplici" in quanto potrebbero aggiornare, eliminare, qualunque altro record in altre tabelle.

Quindi, a mio parere (correggimi se sbaglio) sembrerebbe che usare un ORM sia piuttosto difficile dato che

  1. Non riesco ad accedere direttamente alle tabelle: devo usare una stored procedure
  2. Le stored procedure non sarebbero mappate a CRUD

Sono propenso a definire i repository per isolare il livello del dominio dal database, ma temo che avrei bisogno di definire molte infrastrutture (cache, unità di lavoro e simili) che ottengo per "gratis" in un ORM.

Qualche informazione?

    
posta Stecy 13.10.2011 - 22:05
fonte

2 risposte

3

Sono quasi nella stessa situazione; il nostro database si basa interamente sui proc memorizzati e non possiamo introdurre un ORM poiché tutto dovrebbe essere riscritto per farne uso. Quello che ho fatto è stato scrivere un livello di astrazione, fondamentalmente un'implementazione del pattern Table Data Gateway (anche se io lo chiamo Repository, non è la vera definizione DDD) che astrae la chiamata a SqlCommand e ai suoi amici. Poi ho un Service Layer che si limita a quello che si collega al repository e chiama i metodi su di esso, restituendo oggetti business (essenzialmente DTO), a volte con una collezione interna di un altro oggetto business (il mapping gestito dallo sproc e mappato nel codice ).

Non è perfetto ma nasconde graziosamente i dettagli disordinati dell'utilizzo di una stored procedure.

    
risposta data 13.10.2011 - 22:28
fonte
1

Usiamo un livello DAL che non solo fa la roba SQL ma gestisce l'astrazione. La responsabilità del livello DAL consiste nel prendere un oggetto generico chiamato oggetto di trasferimento dati. L'oggetto di trasferimento dati contiene un elenco di DAL POCO. Il DAL esamina ogni POCO (decoriamo la classe con gli attributi) e genera dinamicamente una classe mapper basata sul tipo di oggetto. Da lì, si tratta solo di mappare le proprietà POCO ai parametri delle stored procedure. Il DAL è molto semplice, basta salvare, eliminare e interrogare sull'interfaccia insieme a un comando personalizzato quando si vuole fare qualcos'altro (chiamare una stored procedure diversa da quella di base per l'inserimento, l'aggiornamento, l'eliminazione, la ricerca) per una certa estensibilità.

Il DAL non si preoccupa veramente del Dominio, è legato allo schema. Pertanto, i POCO utilizzati dal DAL potrebbero essere associati a POCO di domini diversi nel livello del dominio. Quindi in alcuni casi potrebbe esserci un livello intermedio, ma è possibile utilizzare i POCO utilizzati dal DAL in quanto sono solo oggetti di stato e non contengono alcun metodo o logica, ma a volte il dominio e il DAL non corrispondono realmente questo è il momento in cui il dominio sarebbe responsabile della conversione dell'oggetto dominio in un oggetto DAL / POCO.

Da un punto di vista DAL, al momento stiamo supportando 50 delle tabelle ~ 200 pianificate con questo modello, immagino che questo sia un lite ORM nazionale. Con alcuni generatori di codice che abbiamo implementato, la maggior parte e il codice di mappatura (codice noioso della colla) vengono gestiti automaticamente, così possiamo concentrarci sulla logica di business e di presentazione.

Ma è così che l'abbiamo fatto con il 100% di Sproc.

    
risposta data 14.10.2011 - 04:31
fonte

Leggi altre domande sui tag