Questo cattivo design? Come può essere migliorato?

Ho scritto quanto segue qualche tempo fa, ma sono venuto a recensirlo di recente, e ora non penso che sia un buon design.

Il design è per una sorta di livello di database modulare che utilizza Entity Framework 4. Esiste un singolo oggetto di database che carica (pigramente) contesti di framework di entità da librerie esterne in una posizione specificata e le istanze dei contesti caricati sono archiviate in una tabella hash contro il loro nome (ad es. "ContentMgmtContext").

Tutti i contatti con il database in questo sistema avvengono tramite stored procedure. Per effettuare una chiamata al database, la firma del metodo di query è simile alla seguente:

List<TReturn> Query<TReturn>(string Context, 
                             string Procedure, 
                             TransactionScope Scope, 
                             List<ObjectParameter> QueryParameters)

Questa modularità è qualcosa che mi piace. Tuttavia, questo approccio presenta un inconveniente significativo: when using the database layer, the code using it has to have a reference to the library in which the context is stored, in order to access the types returned by the stored procedures through Entity Framework.nel modello, gli oggetti dal livello database vengono tradotti in nuovi oggetti utilizzati dalla vista e dal controller.

Penso che questo sia un cattivo design, ma come posso migliorarlo? Ho considerato l'aggiunta di un'interfaccia vuota come quella IStoredProecedureObjectdi assegnare a ogni tipo di dati restituito da una procedura memorizzata un tipo di base comune, tuttavia questo sembra essere sventato da Entity Framework. Ogni volta che il .edmxfile viene ricompilato, il codice viene generato di nuovo e tutte le aggiunte rimosse. C'è un modo per impedire che ciò accada?

Come posso migliorare questo design? Cosa (altro) c'è di sbagliato in questo? O sono sulla strada giusta?

Dichiarazione di non responsabilità: non utilizzo un framework di entità e sono fortemente distorto rispetto a qualsiasi framework di supporto per database.

Sembra che tu abbia realizzato un involucro.

Faccio una distinzione tra "wrapper" e "layer". Il livello è qualcosa che potresti compilare nella sua propria DLL / project / Jar / qualunque cosa. Il livello di accesso ai dati. Il wrapper è una classe "helper" che usi all'interno di quella DLL. Allo scopo di semplificare l'interfaccia, o forse eliminare la duplicazione.

Il problema con la semplificazione dell'interfaccia di accesso al database è che di solito non è semplice. O finisci per duplicare l'interfaccia di ADO / JDBC / ecc. O costringi le persone a bypassarlo. I wrapper tendono a fare ogni sorta di cose indesiderate. Potrebbero chiudere automaticamente una connessione quando è necessaria per supportare una transazione. Spesso lasciano erroneamente aperte le connessioni se devi trasmettere i dati in streaming e stanno utilizzando una di quelle lingue raccolte in modo errato. Per dare tutta la potenza della libreria dietro il tuo wrapper sei costretto a duplicarlo.

Librerie come ADO / JDBC sono già un'ottima interfaccia. Sono alcuni dei migliori esempi di OOP fatti nel modo giusto. Preferirei usarli sopra un involucro con un mulinello tirato fuori dal suo cappello.

La classica interfaccia in stile JDBC / ADO è ben nota e compresa. L'involucro che ti sei tolto dal cappello non lo è.

Vuoi ridurre "parametri" ridondanti? Guarda i generici. O semplicemente accettalo provando a ridurre "paramter.Add" in realtà semplicemente spingi ".add" su un altro livello di codice.

A proposito, questa è un'ottima domanda. Voterei 10 volte se potessi.

Modifica: ovviamente il codice JDBC sarebbe nascosto nel livello di accesso ai dati.