Cosa penseresti di un nuovo strumento di persistenza Java, che in realtà non è un ORM? [chiuso]

Penso che tu sia sulla strada giusta e dovresti continuare con la tua soluzione. Alcune delle precedenti critiche sono eccessivamente dure, ma alcuni punti validi sono stati fatti.

Anch'io ho cercato a lungo e duramente una soluzione ORM completa che potesse soddisfare le mie esigenze, ma tutte le soluzioni che ho esaminato sono venute meno. Ognuno ha i suoi pro e contro, ma nessuno ha davvero fatto tutto ciò che volevo. Sono d'accordo con le tue critiche a queste soluzioni, vale a dire che sono generalmente complesse e hanno una curva di apprendimento ripida.

Il primo contendente dovrebbe essere lo standard di fatto, Hibernate. È completo, robusto e ben collaudato. Lo rispetto e lo apprezzo per quello che è. Ora, a rischio di offendere metà della comunità di programmatori, devo anche dire che si tratta di un codice prolisso e complesso di codice non performante. Ho passato una discreta quantità di tempo a curiosare nelle sue viscere, cercando di fare il debug e capirlo, e non ero impressionato da quello che vedevo. Detto questo, lo raccomanderei comunque come punto di partenza per chiunque cerchi un buon ORM. Eccelle con il semplice CRUD, ma non lo userei per le query complesse performanti, come il data mining o il crunching dei numeri.

Sfortunatamente, la mia applicazione è più una varietà di numeri che crunch (anche se c'è un po 'di CRUD), quindi ho deciso di fare il mio. Sapevo fin dall'inizio che sarebbe stato paragonato alle altre soluzioni là fuori, ma sarebbe stato abbastanza buono e mi avrebbe dato le prestazioni di cui avevo bisogno. Ora ecco la parte davvero fantastica: assomiglia molto alla tua soluzione!

Questo è quello che penso che tu abbia fatto meglio: hai affermato le tue convinzioni di base come una sorta di dichiarazione di missione, e quelle credenze sono corrette. Ovviamente ho speso una buona quantità di tempo pensando anche a questo problema, ed è difficile da risolvere. Ma col passare del tempo, penso che la comunità di programmazione capisca meglio e creeremo soluzioni migliori. Complimenti a tutti gli sforzi precedenti (specialmente ad Hibernate), ma penso che possiamo fare di meglio.

La tua soluzione perfeziona il problema, ma risolve solo una parte di esso. Penso che un approccio a più livelli possa darci tutto ciò che vogliamo. Quello che hai creato / IMO, è il livello di base. Come suggerito, penso che questo strato sia generato automaticamente in base a uno schema di database. Dovrebbe essere un modello di oggetto relazionale molto semplice che mappa direttamente sul database e non di più. Hai ragione che i dati persistono molto più a lungo del codice, quindi a questo livello i dati dovrebbero guidare il codice e non viceversa. Supporrebbe CRUD e query complessive performanti. Probabilmente implementerò una sorta di cache L1 a questo livello.

Tuttavia, la cosa su cui eccellono le altre soluzioni ORM è la capacità di definire i propri oggetti in un modo che non dipende tanto dalla struttura effettiva del database sottostante. Per questa funzionalità, vorrei creare un altro livello. Per necessità questo strato diventa più astratto, si spera più semplice (a scapito della funzionalità persa) e si basa sul livello precedente. Potrebbe utilizzare una cache L2.

Sono aperto ad avere più livelli, ma il punto chiave per me è che, fornendo più punti di ingresso nella libreria, è possibile soddisfare ogni esigenza. Per coloro che vogliono una soluzione CRUD semplice che mappa direttamente agli oggetti di loro scelta, possono costruire sul livello superiore. Per coloro che sono alla ricerca di qualcosa di più potente e performante ma disposti a subire la complessità aggiunta, possono inserirsi nel livello inferiore. Non vorrei creare un linguaggio di query speciale, ma invece esporrei il tuo oggetto generatore di query per questo scopo. E poiché il codice è stratificato, tale funzionalità esiste naturalmente senza pass-through speciale.

Penso che tu abbia una comprensione dello spazio e non stia reinventando la ruota, ma piuttosto abbia colpito una nicchia leggermente diversa. E francamente, questa è una ruota che potrebbe comunque essere migliorata. Affronta una dura battaglia contesa contro le centrali elettriche del passato, ma se la tua soluzione è buona, e penso che si stia dirigendo in quel modo, allora guadagnerà popolarità per i suoi meriti.

"Ci sono molti di proiettili magici là fuori, e non mancano sviluppatori ingenui. "

Senza offesa, sembra che tu non capisca completamente cosa è stato fatto in questo spazio già e quindi stai reinventando alcune ruote - l'esperienza ci direbbe che tutte le ruote che hai inventato, mentre sono pulite e divertenti, non sono propense a essere quasi buono o utile come le ruote ben rifinite già disponibili.

Uno scenario che renderebbe questo tipo di API adatto è quando hai bisogno di un builder SQL indipendente dal database che la maggior parte dell'ORM non ti consente di avere. Una grande situazione in cui ho avuto bisogno è nella generazione di report. Ho avuto bisogno di costruire SQL in modo orientato agli oggetti e di eseguire questo sql su vari database per il test. Hibernate e altri ORM dipendono molto dalle configurazioni, limitando così la mia costruzione sql in modo tale che non riesco a combinare la tabella in cui l'associazione non esiste negli xmls. Dal momento che qualsiasi associazione è possibile nel modulo di report che sto sviluppando, ho cercato qualcosa di diverso. Poi mi sono imbattuto in JOOQ. Risolve il mio problema. Ho appena avuto bisogno di un accesso di sola lettura, non ho mai riscontrato problemi di debugging come in ibernazione.

In realtà sto pianificando di sviluppare un modo diverso di modellare i dati piuttosto che il comune modo POJO e utilizzare JOOQ come una delle fondamenta che è un livello per creare SQL. Quindi, oltre a JOOQ, sto progettando di creare un modo più flessibile di modellare dati / entità usando HashMaps. Il mio design renderebbe possibile integrare il front-end e il back-end in un punto di accesso, anche se utilizzerei vari livelli per completare il framework, proprio come hanno detto i commenti precedenti. JOOQ giocherà davvero molto bene come nel mio progetto, serve come una delle basi o pilastri.

Quindi continua con il buon lavoro Lukas!

Se comprendo correttamente il tuo strumento, mappa gli oggetti direttamente in una struttura concettuale SQL piuttosto che mappare oggetti che implementano alcune mappature alla funzionalità SQL (ORM), quasi come un'astrazione ORM-- per un maggiore controllo geniale in modo che tu possa usare più funzioni SQL di solito gli ORM non ti danno?

Non sei sicuro del problema che stai cercando di risolvere. Dal momento che il tuo strumento richiede una conoscenza approfondita di SQL, le persone non dovrebbero semplicemente usare, bene, SQL? È il codice della colla che stai cercando di eliminare? Migliore convalida delle query SQL tramite la modellazione API invece delle stringhe semplici?

Devo ammettere che i tuoi esempi JOOQ assomigliano alle versioni LISP di SQL. Non che sia una cosa brutta :) e vedo che alcune delle cose avanzate sono interessanti, ma i vantaggi elencati scompaiono lentamente man mano che si diventa sempre più avanzati (più config, meno astratto, più radicato nel sancta sanctorum dello specifico SQL motore, ecc.)

Un suggerimento che mi piacerebbe vedere che mi manchi nella maggior parte degli ORM è un framework che può trattare gli oggetti in modo non relazionale, traducendo le interazioni Object in qualunque sia il back-end (SQL, NoSQL, Topic Maps, RDF, ecc.) Che richiede la memorizzazione nella cache del Modello usato piuttosto che le specifiche delle interazioni SQL, dialetti e pensiero relazionale.

IMHO, ovviamente. :)