Livello dati senza ORM: come lavorarci in modo efficiente?

La mappatura relazionale degli oggetti senza ORM può essere dolorosa e in qualche modo ripetitiva. Un libro non sarebbe sufficiente per affrontare tutti gli aspetti di questo problema e vi assicuriamo che non siete soli in questa situazione.

Capisco dalla tua domanda che sei più interessato alle query complesse. Per questo argomento specifico, puoi prendere in considerazione il modello di progettazione dell'oggetto query . Potrebbe consentire di riutilizzare query SQL complesse. In questo progetto, i criteri sono anche oggetti (composizione) che potrebbero, ad esempio, aiutare a generare le clausole SQL WHERE. Questo risulta essere molto più conveniente da usare rispetto alla generazione dei comandi SQL con concatenazione di stringhe noiose qua e là nel codice.

A questo proposito, posso consigliare vivamente " Modelli di architettura aziendale " di Martin Fowler, che offre begli esempi di questo modello e affronta molti altri punti utili nella tipica applicazione OO con l'integrazione inebriante del database.

I'm just curious: does anyone else have such problems?

Sì, li ho anche io. Immagino che chiunque non usi gli ORM, alla fine, passi attraverso la stessa situazione.

How did you solve it?

Evito soluzioni troppo generiche, perché altrimenti corro il rischio di implementare il mio ORM !!

Potresti pensare di dover rendere la tua implementazione il più generica e astratta possibile. Per il bene dei principi SOLIDI. Ed è vero

Tuttavia tieni presente che il tuo obiettivo principale è l'applicazione, non la creazione di un framework durante il processo.

Quindi, l'implementazione di codice riutilizzabile e parametrizzato va bene, ma solo se queste caratteristiche vengono indirizzate in modo appropriato per risolvere i reali bisogni del progetto. Per andare oltre è l'overengineering.

Con il rischio di creare codice meno riusabile, un approccio sta rendendo i DAO meno generici. - I generici, ad un certo livello, sono considerati anche anti-pattern -.

Adattare i DAO alle esigenze dell'azienda è un modo per farlo.

Non c'è bisogno di dire che i componenti degli strati superiori dovrebbero rimanere inconsapevoli di questi problemi. In caso contrario, suggerisco di rivedere il design.

Inoltre, potresti essere interessato alle librerie basate sulla mappatura delle righe. Ad esempio, in java, c'è MyBatis che penso sia disponibile anche per .Net. Non oserei chiamare MyBatis come un ORM come EF o Hibernate, ma come una biblioteca per essere estratto dal database che ha risolto molti dei problemi che potresti subire.

Se non puoi permetterti il costo di integrare più librerie, nel mio progetto attuale, ho implementato l'approccio descritto qui (con alcune personalizzazioni). Funziona come un fascino. Riequilibra la riusabilità e la parametrizzazione.

Sfortunatamente, la Specifica è considerata da alcuni come anti-pattern. Qui il riferimento .

Suggerirei di refactoring incrementale del codice usando un micro-ORM come Dapper. È leggero, altamente performante e consente di continuare a utilizzare le istruzioni SQL tradizionali, se è quello che preferisci. Dapper è la mia scelta goto quando non posso usare o non voglio usare qualcosa di più pesante come Entity Framework o Nhibernate.

Un modo per farlo è abbracciare completamente SQL, invece di mescolare le tue metafore.

Ad esempio:

var user = context.ExecuteQuery("SELECT * FROM User WHERE UserID = {0}", userID);

Restituisce una raccolta List<User> (contenente un record, in questo caso).

Dapper ed Entity Framework sono entrambi capaci di query come questa. Puoi renderli elaborati come vuoi, eseguire più query e creare oggetti dati complessi in questo modo.

Potresti anche codice generare metodi CRUD, se sei così inclinato.

Ho cercato nella proprietà. L'entità avrà molte proprietà. Class PropInt avrà il valore di ritorno e anche come costruire la ricerca. La creazione di una ricerca su Int è la stessa: è sufficiente conoscere il nome della tabella e della colonna.

Utente iEnumerable e DataReader

public iEnumerable<SomeEntity> GetEntities(SomeEntity someEntity);