ORM nel mondo reale

Question

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.

Saluti. Josh

Answer 1

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.

Answer 2

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.

Answer 3

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:

1. 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.

2. È 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.

Answer 4

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.