L'implementazione agnostica rimane davvero valida?

so that at some point in the future I can swap out my ORM implementation. I severely doubt that will ever happen over the life of the product, so I'm essentially putting effort into something that I'll probably never reap the benefits of

Nella mia esperienza, il progetto aziendale tipico non viene mai scambiato:

1. database
2. ORM
3. Lingua

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

Più spesso che scambiare un ORM, vuoi sapere di cosa ho visto di più? Rimozione completa dell'ORM per passare all'SQL a causa di problemi di prestazioni. Quindi non importa cosa, in quel caso, stai per riscrivere le cose.

Per quanto riguarda l'implementazione agnostica, è un mito. Davvero equivale a sminuire. Quindi il mio approccio è quello di abbracciare il livello dati. Rendilo una parte di prima classe della tua lingua e del tuo design. Fa 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 sopravvivrà all'applicazione per anni, forse per decenni.
A meno che, naturalmente, non vi sia stato dato di capire fin dall'inizio che il database è pianificato per essere sostituito da qualcos'altro nel prossimo futuro.
Se lo stai scrivendo per la vendita ai clienti, che possono avere diversi motori di database, E i requisiti sono tali che supporterà supportare più motori di database, POI ha senso.

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

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

Is "programming to the interface" worth it when it comes to stuff like JPA?

Lo è, ma non ha nulla a che fare con JPA in particolare. Puoi fare "programmazione sulle interfacce" di Hibernate. Non si tratta di nascondere un framework sotto uno standard, si tratta di SOLID .

Have you ever actually swapped an entire ORM implementation in a product?

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

Non vedo la possibilità di scambiare Hibernate con un altro ORM compatibile con JPA.

Have you ever been able to completely avoid the abstraction from something like JPA leaking anyways?

No. È impossibile perché sia JPA che Hibernate sono molto complessi. E devi affrontare comunque i problemi di performance 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 il tuo ORM o provider di database in quanto tale. È più una questione di separazione delle preoccupazioni e di agilità.

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

Se sai che la tua implementazione ORM è Hibernate, questa conoscenza inizia a filtrare tutta l'architettura della tua applicazione. E ogni volta che arriva una nuova tecnologia che sostituisce Hibernate o JPA in modo così completo come Hibernate ha fatto a qualsiasi cosa venisse prima, si scopre che le dipendenze sono diventate molto più profonde di quanto ci si aspettasse.

È molto meglio mettere da parte l'intera preoccupazione di mantenere il tuo modello da qualche parte fuori mano, dove tutte le complessità dei rapporti con database e transazioni e quant'altro, possono essere facilmente ignorati dal resto dell'applicazione. In quel remoto angolo buio, puoi legarti in nodi su specifici dettagli di implementazione, se vuoi: non importa più.

Il problema con l'agnosticismo nell'implementazione è che, nel tuo tempo come sviluppatore, perderai tempo inutile.

Ho scritto diversi progetti che abbiamo sprecato un sacco di tempo scrivendo su un'interfaccia, che non sono mai stati utilizzati in alcun modo nuovo, non sono mai stati convertiti e sono stati usati "così com'è" per anni

Ho anche sprecato un carico di tempo per convertire software che nessuno avrebbe mai dovuto convertire.

L'unica osservazione reale che devo fare è che il primo è molto meno doloroso.