I migliori argomenti per / contro l'introduzione della tecnologia ORM in un processo di sviluppo delle aziende [chiuso]

Direi che alcuni progetti si prestano ad essere più facili da lavorare con gli ORM di altri. La mia attuale compagnia ha tre cose importanti che hanno reso ORM una decisione immediata:

1. L'applicazione è molto semplice in quanto fa CRUD contro gli oggetti di base.
2. Ci sono pochissimi join coinvolti quando si tratta di mostrare i dati agli utenti negli elenchi.
3. C'è pochissima contesa sui record e, come tale, non è stato necessario prendere decisioni in merito alle transazioni e alle conseguenze del blocco dei dati.

Oltre a ciò, ricorda, le persone con DB sono molto avverse al rischio mentre quelle di Dev sono molto più adatte al rischio. Questa domanda diventa molto di più sulla psicologia umana.

Recentemente siamo passati ad un approccio basato su ORM e posso darvi alcuni aspetti negativi, ma è difficile trovare utili positivi. La maggior parte di questo è dovuto alla natura del nostro database.

Pros (si noti che entrambi potrebbero essere considerati come l'utilizzo degli SP, gli ORM li rendono più semplici, tuttavia):

• Quando è qualcosa di bello e semplice, sarà performante e pulito.
• Gran parte della logica viene estratta dagli SP e può quindi essere testata.

Contro:

• Quando non è bello e semplice, l'SQL sarà spazzatura. Potresti non recuperare i dati che ti aspetti. Sarà lento e sarà incredibilmente difficile da sintonizzare.

• Il nostro database è in costante cambiamento. Ciò significa che ogni paio di giorni qualcuno ha bisogno di passare un'ora ad aggiornare il modello per aggiungere una tabella o cambiare i tipi di dati che stanno cambiando (agile + ORM su un grande database in continua evoluzione è brutale).

Perché deve essere tutto o niente? Non c'è nulla che impedisca a un DBA o sviluppatore di database di creare una sorta di vista, udf o stored procedure per gestire qualcosa che ritengono eccessivamente complesso o che vogliono avere il maggior controllo possibile.

Ci sono modi per catturare lo sql che si sta creando.

Le prestazioni dello sql generato da ORM possono essere paragonate a qualcosa di più ottimizzato.

Ad un certo punto la creazione e il mantenimento del codice devono essere una considerazione.

Per quanto mi riguarda, l'unica ragione legittima che ho sentito per l'uso della mappatura relazionale degli oggetti (ORM) è se è probabile un passaggio a un motore di database diverso (non solo possibile). Da MySQL a Oracle sarebbe un esempio (anche se non so perché qualcuno desidererebbe apportare quel particolare cambiamento a meno che non sia assolutamente necessario). E anche in questo caso un ORM potrebbe non essere la decisione migliore.

Ho sentito un riferimento che mi ha infastidito che ha suggerito che sono i programmatori meno competenti contro ORM. Si potrebbe facilmente dire che è un programmatore incompetente in SQL che è a favore di ORM. Quindi non facciamo questo tipo di argomento.

Le ragioni per le quali sono contrario all'ORM sono che ritengo che tolga la trasparenza e renda difficile apportare le inevitabili modifiche in corso che rappresentano una parte importante di tutto il ciclo di sviluppo. Se uno sviluppatore non è fluente in un particolare ORM e viene assunto e ha bisogno di apportare modifiche al database, un'attività che potrebbe richiedere un altro ora potrebbe richiedere molte ore. Quindi lo sviluppo di un'applicazione "rapida" diventa "paralizzante" la manutenzione dell'applicazione.

Credo anche che i modelli di progettazione complessi in cui una lingua scrive automaticamente un'altra lingua dovrebbero essere generalmente evitate. ORM non è l'unico esempio di questo, ovviamente. Un altro esempio è PHP che scrive XHTML. Nota che ogni riga di codice che scriviamo deve essere o dovrebbe essere orientata agli oggetti. Incorporando il nostro linguaggio di markup e la sintassi delle query invece di avere il nostro linguaggio di programmazione "automagicamente", rende l'applicazione più trasparente (più facile da capire), il debug e la manutenzione. Inoltre, alcuni potrebbero dire che un ORM "libera" i progetti dai vincoli di un particolare motore di database. Ma per quanto riguarda i vincoli del tuo nuovo motore ORM "fadish"? Puoi praticamente garantire che i principali motori di database saranno supportati più a lungo della maggior parte degli ORM.

Vorrei anche sottolineare che ORM non è VMC, anche se molti VMC sono in bundle con ORM. È perfettamente valido, e penso che sia desiderabile nella maggior parte dei casi, creare modelli che contengono metodi fatti a mano con SQL scritto a mano.

Vorrei anche smentire un altro mito: che gli ORM siano collegati al RAD o allo sviluppo rapido di applicazioni. Non lo compro perché nella mia esperienza personale spendo solo il 10% del mio tempo a scrivere modelli SQL e crafting per CRUD. Quindi, anche se ORM ridurrebbe questo tempo a metà (e non credo che lo faccia), allora sarebbe solo un aumento del 5% nel mio tempo di sviluppo (che non è). E io non sono un esperto di SQL o DBA - solo uno sviluppatore con competenze SQL medie. SQL non è solo un grosso spreco di tempo finché il principio di DRY viene seguito e i modelli vengono creati con intenzione.

Personalmente ritengo che ci sia un sacco di "pensieri di gruppo" attorno a ORM - che gli sviluppatori dicono che dovrebbe essere usato perché tutti gli altri dicono che dovrebbe essere usato; è considerata una tecnologia "calda" con cui è possibile recuperare un curriculum. Mettilo sul tuo curriculum se ritieni di doverlo fare, ma non utilizzarlo in un progetto importante solo perché ritieni che "dovresti".

So, I'm looking for the best or most convincing arguments that you have put forward FOR the use of ORM tools.

Non c'è modo di convincere chi è contro ORM.

Tuttavia, dimostra che ORM è migliore. Ma puoi farlo solo con un'implementazione ORM pienamente funzionante che funziona, è veloce e molto più semplice di SQL equivalente.

Inoltre, dovrai mostrare come attivare la registrazione in modo che possano vedere passare SQL.

1. Scegli un progetto che abbia un livello controllato di complessità. Riscrivere un'applicazione esistente ma rotta è spesso la migliore. La struttura dei dati è stabile, i casi d'uso sono noti e tu fabbrichi una suite di test unitaria per misurare la correttezza e le prestazioni.

2. Implementa quel progetto con un'implementazione ORM super pulita. Super pulito. Niente hack Nessun rimedio. Niente di "divertente" o al di fuori del tutorial.

3. Metti in produzione.

4. Esegui manutenzione.

5. Dimostra di averlo fatto più velocemente, con meno errori e che è possibile eseguire la manutenzione più rapidamente a causa dell'ORM. Ciò richiederà un anno o più.

Nella nostra azienda abbiamo questo contro argomenti per ORM come:

We want control over our SQL.

Non so quanta differenza farebbe, ma ho sempre trovato questo argomento.

Sono contrario all'ORM e all'astrazione del database in generale perché:

1. Incoraggia le persone a mettere la logica aziendale (incluso il controllo degli accessi) nell'applicazione (o nella libreria) e non nel database. Questo è male, perché significa che se è necessario eseguire 1 app in una lingua diversa, la logica deve essere coerentemente reimplementata. Significa anche che tutti gli sviluppatori devono essere considerati affidabili con tutti i dati.
2. I modelli ORM che ho visto sono davvero intolleranti alle modifiche alla struttura del database. Pertanto, quando un campo viene aggiunto a una tabella per 1 app, tutte le app devono essere ricostruite / ridistribuite contemporaneamente, possibilmente attraverso più lingue di sviluppo e posizioni geografiche. Questo è un incubo di manutenzione.