ORM nel mondo reale

Sto iniziando un nuovo progetto che penso durerà per alcuni anni. Sono nel punto di decidere il framework ORM da usare (o se usarne uno affatto). Qualcuno con esperienza può dirmi se i framework orm sono usati nelle applicazioni di realworld. Il problema che ho in mente è questo: lo strumento orm genererà per me tabelle e colonne ecc. Mentre creo e modifico le mie entità. Tuttavia, dopo che il progetto è attivo e in produzione, alcune modifiche al database non saranno possibili. Questo può ostacolare il progresso del progetto. Se avessi usato un framework come ibatis, ad esempio, so che avrei solo bisogno di adattare le istruzioni SQL in base alle modifiche del database. Qualcuno può dirmi se gli strumenti ORM sono sopravvissuti all'ambiente live. Nel mio ufficio, utilizziamo l'ERP basato su java che è stato eseguito molto tempo fa e non è mai stato utilizzato alcun framework ORM.ORM nel mondo reale

Saluti. Josh

fonte

2010-04-20 josh

Utilizzare solo schemi generati automaticamente per lo sviluppo iniziale e la prototipazione. Il DDL generato non soddisferà quasi mai alcun DBA esperto. Inoltre, il database andrà a vivere più a lungo rispetto all'attuale codice applicativo, quindi vale la pena dedicare del tempo al suo design.

Quando si sceglie un mapper, optare per uno flessibile e stare lontano dai mappatori ossessionati dagli oggetti, poiché spesso supportano solo una limitata personalizzazione del database. Mi viene in mente l'integrazione con le stored procedure povere di Hibernates, così come manca il supporto per i mapper dei tipi personalizzati.

mapper oggetto come iBatis e EclipseLink sono scelte sicure in quanto consente di mappare quasi tutto, assicurando che è possibile creare sia un grande modello di dominio e un design dello schema ingegnoso. Si noti inoltre che Spring JDBC ha compiuto un lungo percorso (in particolare il molto utile SimpleJDBCTemplate), quindi mentre tecnicamente non è un ORM, esso consente di fare tutto ciò che si desidera senza scrivere il noioso codice JDBC.

fonte

2010-04-20 09:08:55

Chiarire perché un quadro ORM non deve essere "ossessionato dall'oggetto" e come Il framework ORM consente di "rifattorizzare lo schema del database". – ireddick

Un buon ORM dovrebbe soddisfare sia gli amministratori di database che gli sviluppatori di applicazioni. Voglio avere sia un'ottima progettazione del database che un grande modello di oggetti. Mapper come Hibernate costringono il design del database ad essere in un certo modo, che trovo molto limitante. –

Questa risposta accettata esprime un punto di vista molto personale e non illustra la percezione generale del valore aggiunto di ORM e quando usarli o meno. In primo luogo, si suppone che gli ORM generino l'SQL, il supporto delle stored procedure è solo una funzione. Tuttavia, l'utilizzo della stored procedure non è la filosofia di ORM (non utilizzare un ORM se si utilizzano procedure memorizzate). In secondo luogo, confrontare Hibernate e iBATIS è come confrontare mele e arance (nemmeno menzionare Spring JDBC), iBATIS non è un ORM, è un mappatore di dati. Ma è vero che gli ORM non si adattano bene agli schemi esoterici. –

Ho usato per diversi anni nella produzione Hibernate + JPA. Non ho mai fatto affidamento sulla generazione dello schema ORM e penso che questa sia una cattiva pratica in generale, dal momento che non si ha il pieno controllo dello schema in questo modo e ORM non genererà sempre lo schema ottimale. Utilizzando qualcosa come Liquibase per il monitoraggio delle migrazioni dello schema in una migliore idea IMO.

fonte

2010-04-20 08:53:53

da una prospettiva basata sul dominio, non è necessario essere in controllo dello schema. In effetti, non ti interessa sapere esattamente come il tuo modello di dominio è rappresentato come uno schema relazionale. – Bozho

Bozho, in ambiente di produzione, ti interessa come il tuo modello di dominio è rappresentato come un database relazionale. Dopo aver messo in produzione la tua applicazione, non puoi più apportare modifiche al database come desideri. Nella maggior parte dei casi, qualcun altro prenderà il controllo del database. – josh

@Bozho, teoria e pratica raramente convivono pacificamente. Ho notato bug negli ORM che hanno generato uno schema non corretto o non ottimale. Inoltre ci sono progetti che utilizzano ORM che hanno come target solo un DB specifico ei client insistono sull'uso di tutte le ottimizzazioni db possibili - non graziose, ma sai cosa dicono - il cliente ha sempre ragione ... –

Gli ORM sono utilizzati molto ampiamente nelle applicazioni del mondo reale. Il problema modifica dello schema che lei ha citato è tipicamente trattata in uno dei due modi:

Come suggerito da risposte precedenti, è possibile mantenere lo schema manualmente nel database e avere l'ORM aggiornare lo schema per corrispondere ciò che vede nel database.
È possibile fare in modo che l'ORM verifichi lo schema del database rispetto alle proprie informazioni sul modello di oggetto e generi le query necessarie per l'aggiornamento in caso di modifiche.

Nella mia esperienza, qualsiasi ORM decente dovrebbe essere in grado di gestire # 1 e la maggior parte sembrano essere in grado di gestire 2 #, ma non è altrettanto universale.

Per quanto è meglio, bene ... Dipende molto da come si visualizza la relazione tra il database e il modello di oggetto.

Se il tuo interesse principale è sul database e utilizzi un ORM per fornire un wrapper OO attorno alle tabelle e ai campi per renderli più facilmente accessibili, probabilmente vorrai andare con il n. 1 e mantenere il pieno controllo su il database.

Se, d'altra parte, si vede il modello di oggetto come supremo e si utilizza principalmente il database come un meccanismo di persistenza stupido, con l'ORM che serve a semplificare tale attività, allora probabilmente si vorrà usare # 2 così è possibile concentrarsi sul modello dell'oggetto e non doversi preoccupare dei dettagli del database sottostante. Oppure si potrebbe voler dare un'occhiata a negozi di chiavi/valori, motori di persistenza del grafico ad oggetti o altre forme di database NoSQL per ottenere un supporto migliore per la persistenza dell'oggetto diretto senza doversi preoccupare delle modifiche dello schema sul lato del database.

fonte

2010-04-20 09:13:16

Grazie Dave. ho qualche commento pensato. Se cambio il database come da opzione uno, devo aggiornare i miei metadati di mappatura - annotazioni o xml. preferisco le annotazioni e ciò significherebbe la ricompilazione e la ridistribuzione. (modifica della versione, processo QA ecc.). Mi piacerebbe evitarlo. – josh

Ho utilizzato Hibernate da alcuni anni e sono molto soddisfatto. Uso il generatore di schemi solo per creare un database nuovo di zecca, ma per gli aggiornamenti utilizzo gli script sql creati dall'uomo.

Non credo sia possibile automatizzare in modo affidabile l'aggiornamento dello schema: se si rinomina un campo per esempio, uno strumento automatico rimuove il campo e ne aggiunge uno nuovo, perdendo così il contenuto.

fonte

2010-04-20 09:59:50

risposta

Problemi correlati