La cattiva progettazione del software consente di combinare le chiamate JDBC SQL e utilizzare un ORM in un'applicazione? [chiuso]

Dipende dalle esigenze dell'applicazione. Ad esempio, ho lavorato per il settore bancario e, quando devi generare migliaia di ordini di pagamento delle fatture, è meglio avere una stored procedure per eseguire l'attività (sarà molto più veloce) e aggiornare direttamente le tabelle del modello nel database.

Quindi puoi mostrare i risultati con ORM, anche aggiornare un ordine di pagamento (ma non migliaia).

Se la tua applicazione non è critica dal punto di vista delle prestazioni, è meglio programmare la manutenibilità per gestire ORM, in modo che non sia necessario conoscere la tecnologia DB sottostante.

Ancora una volta, dipende dalle tue esigenze e se mantieni il codice organizzato e pulito (applica un pattern DAO, ad esempio), non è un'architettura cattiva, né un codice non mantenibile.

Di solito è male perché l'ORM memorizzerà i dati nella cache, quindi girando attorno a esso non sarà possibile trarre vantaggio da tale memorizzazione nella cache. Inoltre, non puoi condividere cose come le dichiarazioni preparate. Se mescoli troppo le cose, potresti anche finire con un deadlock se il tuo codice JDBC e l'ORM non usano la stessa strategia di blocco, o hai problemi di promozione della serratura.

Alcuni ORM forniscono la possibilità di eseguire istruzioni all'interno dello stesso contesto dell'ORM, che può eliminare molti dei problemi.

I relatori di oggetti non sono una proposizione del tutto o niente. Usi gli ORM in modo da non dover passare attraverso la noia di scrivere query CRUD, che possono comprendere circa l'80% della tua applicazione.

Ma ogni ORM ha ancora un meccanismo per l'utilizzo di SQL raw o stored procedure o consente di scrivere tali procedure al di fuori dell'ORM. Questo ti permette di ottimizzare quella piccola parte del tuo programma (forse il restante 20%) che non si presta in modo soddisfacente alla mappatura ortodossa oggettuale-relazionale.

Dipende. La maggior parte dei framework ORM fornisce un "escape hatch" che consente di eseguire SQL raw, ma ciò che dovrebbe essere nella parte posteriore della tua mente è: "Perché sto facendo questo quando il mio layer ORM è in grado di ricreare un'intera gerarchia di oggetti su richiesta ? "

Direi che veramente calpestare il ghiaccio sottile se stai facendo aggiornamenti al di fuori del tuo livello ORM. Le query probabilmente andrebbero bene se si sta facendo qualcosa che riguarda i report (aggregazione o join), in cui il costo della creazione di gerarchie di oggetti è elevato e fornisce poco valore. Tuttavia, anche allora devi pensare a cosa stai facendo trading. Il motivo per cui utilizziamo gli ORM è tale che possiamo pensare negli oggetti, e scrivendo SQL raw rispetto alle tabelle sottostanti, anche quando si tratta solo di query, stiamo scrivendo il codice che interromperà quando cambiamo il nostro oggetto attributi o relazioni. Che sia un grosso problema o no dipende interamente dall'applicazione.

Quindi, sfortunatamente, la risposta alla tua domanda è: "Dipende".

Direi di sì, probabilmente dovresti evitarlo se possibile.

Il codice viene letto drasticamente più regolarmente di quanto non sia scritto. Quando gestisci un'applicazione, il codice che funziona e si legge nello stesso modo è molto più semplice da mantenere rispetto al fatto che i bit funzionino in un modo e quelli che ne fanno un altro.