Rimanere veramente agnostici sull'implementazione ne vale davvero la pena?

Ho un progetto a cui sto lavorando attualmente utilizzando Tomcat, Spring 4, Spring Security, MySQL e JPA con Hibernate.

Ho scelto JPA dal punto di vista del fatto che si supponga di rendere senza soluzione di continuità, o almeno meno dolorosa, scambiare l'implementazione sottostante dei provider di ORM. Direi che questo utilizza mentalmente le specifiche sull'implementazione (JAX-RS) è il punto di vista predefinito della comunità di sviluppo Java.

Sono curioso di sapere se questo è davvero un compito che vale la pena fare. Sono sicuro che se usassi direttamente Hibernate guadagnerei un po 'di energia perché potrei usare funzionalità che non fanno parte delle specifiche JPA principali.

Parte della mia preoccupazione viene dall'idea di YAGNI. Sto essenzialmente programmando in uno stile e una moda specifici (usando JPA invece di Hibernate) in modo che ad un certo punto in futuro possa scambiare la mia implementazione ORM. Dubito fortemente che accadrà mai durante la vita del prodotto, quindi essenzialmente sto facendo uno sforzo per qualcosa di cui probabilmente non trarrò mai beneficio.

Quali sono i tuoi pensieri? La "programmazione per l'interfaccia" vale la pena quando si tratta di cose come JPA? Hai mai effettivamente scambiato un'intera implementazione ORM in un prodotto? Sei mai stato in grado di evitare completamente l'astrazione da qualcosa come JPA che perde comunque? Personalmente ho già una singola chiamata SQL nativa (per ripulire le tabelle del database), e ci sono alcune cose con cui vorrei futz che sono integrate nelle specifiche JPA (ottenere / impostare i prefissi per i metodi e la differenza tra MEMBER OF / IN, che vincolando solo me stesso a un'implementazione di base mi darà qualche possibilità di evitare.

in modo che ad un certo punto in futuro possa scambiare la mia implementazione ORM. Dubito fortemente che accadrà mai durante la vita del prodotto, quindi essenzialmente sto facendo uno sforzo per qualcosa che probabilmente non trarrò mai beneficio da

Nella mia esperienza, il tipico progetto aziendale non cambia mai:

1. Banca dati
2. ORM
3. linguaggio

Non conosco i numeri, ma la percentuale di app a 2 livelli che ho visto implementare e quindi cambiare una di queste cose sarebbe probabilmente inferiore al 10%. Se succede, è raro e di solito accade entro i primi 2-3 mesi del progetto quando le persone sono ancora in modalità scoperta. La maggior parte dei sistemi che conosco funzionano ancora sulle loro piattaforme originali 8-10 anni dopo.

Più spesso che sostituire un ORM, vuoi sapere di cosa ho visto di più? Rimozione completa di ORM per accedere a SQL a causa di problemi di prestazioni. Quindi non importa cosa, in quel caso, riscriverete le cose.

Per quanto riguarda l'implementazione agnostica, è un mito. Significa davvero smorzare. Quindi il mio approccio è quello di abbracciare il livello dati. Rendilo una parte di prima classe della tua lingua e del tuo design. Rende i progetti più felici e di maggior successo.

ne vale la pena?
Ciò dipenderebbe interamente dall'applicazione.
Se stai scrivendo un'applicazione interna per una singola azienda, dimenticala. Quel database sopravviverà all'applicazione per anni, forse decenni.
A meno che, naturalmente, non vi sia stato dato di capire fin dall'inizio che il database dovrebbe essere sostituito da qualcos'altro nel prossimo futuro.
Se lo stai scrivendo per la vendita ai clienti, che potrebbero avere motori di database diversi, E i requisiti sono tali che dovrebbe supportare più motori di database, quindi ha senso.

Per la maggior parte delle persone che scrivono quindi applicazioni Java, è in gran parte irrilevante.

Dalla mia esperienza: no, non ne vale la pena in caso di JPA / Hibernate.

La "programmazione per l'interfaccia" vale la pena quando si tratta di cose come JPA?

Lo è, ma non ha nulla a che fare con l'APP nello specifico. Puoi fare "programmazione alle interfacce" di Hibernate. Non si tratta di nascondere un framework in uno standard, ma di SOLID .

Hai mai effettivamente scambiato un'intera implementazione ORM in un prodotto?

Sì e no. Uno dei prodotti della nostra azienda è parzialmente migrato da Hibernate a jOOQ (che non ha nulla a che fare con l'APP). Non era esattamente un "tipico progetto imprenditoriale" menzionato da @codenheim, quindi lo scambio era possibile.

Non vedo il punto di scambiare Hibernate con un altro ORM conforme a JPA.

Sei mai stato in grado di evitare completamente l'astrazione da qualcosa come JPA che perde comunque?

No. È impossibile perché sia ​​JPA che Hibernate sono molto complessi. E devi comunque affrontare i problemi di prestazioni di Hibernate e i difetti di progettazione.

A rischio di sembrare contrarian qui, direi che sì, ne vale la pena. E non lo è.

Il problema non è tanto nel cambiare l'ORM o il provider di database in quanto tale. È più una questione di separazione delle preoccupazioni e di rimanere agili.

Una volta che inizi a fare affidamento su alcuni dettagli di implementazione di una libreria, inizi a creare intrecci sempre più profondi di preoccupazioni.

Se sai che l'implementazione di ORM è Hibernate, questa conoscenza inizia a filtrare l'intera architettura dell'applicazione. E ogni volta che arriva una nuova tecnologia che sostituisce Hibernate o JPA in modo così approfondito come ha fatto Hibernate in qualunque cosa gli sia venuta prima, scopri che le dipendenze sono diventate molto più profonde di quanto ti aspettassi.

È molto meglio nascondere l'intera preoccupazione di perseverare nel modello da qualche parte, dove tutte le complessità dei rapporti con database e transazioni e quant'altro, possono essere facilmente ignorate dal resto dell'applicazione. In quel remoto angolo buio, puoi legarti a nodi su specifici dettagli di implementazione, se vuoi, non importa più.

Il problema con l'agnosticismo dell'implementazione è che, nel tuo tempo come sviluppatore, perderai tempo in entrambi i modi.

Ho scritto diversi progetti che abbiamo perso molto tempo scrivendo su un'interfaccia, che non sono mai stati utilizzati in alcun modo nuovo, mai convertiti e usati "così come sono" per anni

Ho anche perso un sacco di tempo nella conversione di software che nessuno si sarebbe mai aspettato di dover convertire.

L'unica vera osservazione che devo fare è che la prima è molto meno dolorosa.