CRUD senza un ORM

3

Sto mettendo insieme un'app web con relazioni di database relativamente complesse ma standard. Ho notato che ogni volta che uso un ORM, in python / ruby / php ecc, in generale, vengono generate molte query. Questo sta affermando l'ovvio. Generalmente gli ORM creano più query del necessario per portare a termine il lavoro. Non sono perfetti.

Potrei creare queste query personalmente. Sembra vecchia scuola ma, molto probabilmente, l'app funzionerà più velocemente e non dovrò scherzare con gli ORM. Invece mi prenderò in giro con SQL. Preferirei scherzare con SQL, piuttosto che con una libreria specifica per lingua / versione.

Non ho paura degli ORM, li ho usati con grande successo in passato.

Mi chiedo come le persone in genere (a livello macro) organizzano il loro codice per supportare query SQL non elaborate.

Ad esempio, supponiamo che io utilizzi un'architettura MVC come nella mia applicazione.

  • Le mie viste sono in HTML con una libreria allettante.
  • I miei controller ottengono i dati dai modelli e li inviano alle viste.
  • I miei modelli mappano singole / più tabelle db a proprietà e metodi in una struttura simile a una classe per un facile accesso.

Dove dovrebbero essere inseriti i comandi sql? Posso immaginare che potrebbe essere una ricetta per codice sciatta o modelli con chilometri di query SQL. Inoltre, renderebbe impossibile aggiungere qualcosa come un ordinamento predefinito. E torniamo di nuovo agli ORM.

Se dovessi pensare a questo, potrei creare un helper sql per ogni modello, che contiene la query. Ti chiedi se ci sono altri modi

    
posta user974407 04.09.2016 - 02:43
fonte

1 risposta

3

Ciò che stiamo facendo nel mio team utilizza l' oggetto di accesso ai dati dedicato per mettere il nostro codice di accesso al DB e archiviare il codice SQL reale nelle stored procedure.

So che sembra antiquato, ma è provato e vero. Abbiamo valutato un framework ORM su insistenza di un particolare membro del team e abbiamo scoperto un problema di selezione N + 1 in un percorso di codice molto banale. Poiché abbiamo esperienza SQL nel nostro team, abbiamo preso la tua stessa decisione.

DAO sembra doloroso? Un sacco di caldaia? Per mantenerlo semplice e pulito, stiamo usando:

  • Spring JDBC per ridurre al minimo la piastra della caldaia (vedi JdbcTemplate e BeanPropertyRowMapper - abbiamo un'astrazione generale che prende un nome stored procedure, parametri e una java.lang.Class e lega automaticamente il set di risultati.
  • Spring for dependency injection consente di effettuare facilmente il cablaggio in DAO e di prenderli in giro per il test.
risposta data 04.09.2016 - 06:26
fonte

Leggi altre domande sui tag