Generatori di codici vs.ORM vs.Procedura di archiviazione

Question

In quali ambiti ciascuna di queste architetture software brilla o fallisce?

Quali requisiti chiave ti spingerebbero a sceglierne uno piuttosto che l’altro?

Si supponga di avere a disposizione sviluppatori in grado di realizzare un buon codice orientato agli oggetti e un buon sviluppo di database.

Inoltre, per favore, evita le guerre sante :) tutte e tre le tecnologie hanno pro e contro, mi interessa dove è più appropriato usarle.

Answer 1

Ognuno di questi strumenti fornisce diversi livelli di astrazione, insieme a diversi punti per sovrascrivere il comportamento.Si tratta di scelte architetturali e tutte le scelte architetturali dipendono dai compromessi tra tecnologia, controllo e organizzazione, sia dell'applicazione stessa che dell'ambiente in cui verrà distribuita.

• Se hai a che fare con una cultura in cui i DBA "reggono il posatoio", allora un'architettura basata su procedure memorizzate sarà più facile da implementare.D'altro canto, può essere molto difficile gestire e controllare la versione delle procedure memorizzate.

• I generatori di codice funzionano meglio quando si utilizzano linguaggi tipizzati staticamente, perché è possibile rilevare errori in fase di compilazione anziché in fase di esecuzione.

• Gli ORM sono ideali per gli strumenti di integrazione, in cui potrebbe essere necessario gestire diversi RDBMS e schemi da installazione a installazione.Cambia una mappa e la tua applicazione passerà dall'utilizzo con PeopleSoft su Oracle all'utilizzo con Microsoft Dynamics su SQL Server.

Ho visto applicazioni in cui il codice generato viene utilizzato per interfacciarsi con le procedure memorizzate, poiché le procedure memorizzate potrebbero essere modificate per aggirare le limitazioni nel generatore di codice.

In definitiva, l'unica risposta corretta dipenderà dal problema che stai cercando di risolvere e dall'ambiente in cui la soluzione deve essere eseguita.Tutto il resto mette in discussione la corretta pronuncia di "patata".

Answer 2

Aggiungo i miei due centesimi:

Procedura di archiviazione

• Può essere facilmente ottimizzato
• Regole aziendali fondamentali astratte, che migliorano l'integrità dei dati
• Fornire un buon modello di sicurezza (non è necessario concedere autorizzazioni di lettura o scrittura a un utente database frontale)
• Brilla quando hai molte applicazioni che accedono agli stessi dati

ORM

• Permette di concentrarsi solo sul dominio e di avere un approccio allo sviluppo più "puro" orientato agli oggetti
• Brilla quando la tua applicazione deve essere compatibile con cross db
• Brilla quando la tua applicazione è guidata principalmente dal comportamento anziché dai dati

Generatori di codici

• Fornisci vantaggi simili agli ORM, con costi di manutenzione più elevati, ma con una migliore personalizzazione.
• Sono generalmente superiori agli ORM in quanto gli ORM tendono a scambiare errori in fase di compilazione con errori di runtime, cosa generalmente da evitare

Answer 3

Sono d'accordo che ci sono pro e contro in tutto e molto dipende dalla tua architettura.Detto questo, cerco di utilizzare gli ORM dove ha senso.Molte funzionalità sono già presenti e di solito aiutano a prevenire l'SQL Injection (in più aiuta a evitare di reinventare la ruota).

Per ulteriori informazioni, consultare questi altri due post sull'argomento (Dynamic SQL vs Stored Procedure vs ORM)

SQL dinamico vs.procedura di archiviazione
Che è migliore:Query ad hoc o procedure memorizzate?

ORM vs.procedura di archiviazione
Perché l'SQL parametrizzato generato da NHibernate è veloce quanto una procedura memorizzata?

Answer 4

Gli ORM e i generatori di codice si trovano da un lato del campo e le procedure memorizzate dall'altro.In genere, è più semplice utilizzare ORM e generatori di codice nei progetti greenfield, perché puoi personalizzare lo schema del database in modo che corrisponda al modello di dominio che crei.È molto più difficile utilizzarli con progetti legacy, perché una volta che il software è stato scritto con una mentalità "data-first", è difficile racchiuderlo in un modello di dominio.

Detto questo, tutti e tre gli approcci hanno valore.Le procedure archiviate possono essere più facili da ottimizzare, ma può essere forte la tentazione di inserirvi una logica aziendale che potrebbe essere ripetuta nell'applicazione stessa.Gli ORM funzionano bene se il tuo schema corrisponde al concetto di ORM, ma in caso contrario può essere difficile da personalizzare.I generatori di codice possono essere una buona via di mezzo, perché forniscono alcuni dei vantaggi di un ORM ma consentono la personalizzazione del codice generato; tuttavia, se prendi l'abitudine di alterare il codice generato, avrai due problemi, perché tu dovrà modificarlo ogni volta che lo rigeneri.

Non esiste una risposta vera, ma tendo maggiormente verso il lato ORM perché credo che abbia più senso pensare con una mentalità incentrata sugli oggetti.

Answer 5

Procedura di archiviazione

• Professionisti: Incapsula il codice di accesso ai dati ed è indipendente dall'applicazione
• Contro: Può essere specifico per RDBMS e aumentare i tempi di sviluppo

ORM

Almeno alcuni ORM consentono la mappatura su procedure memorizzate

• Professionisti: Astrae il codice di accesso ai dati e consente di scrivere oggetti entità in modo specifico del dominio
• Contro: Possibile sovraccarico delle prestazioni e capacità di mappatura limitata

Generazione del codice

• Professionisti: Può essere utilizzato per generare codice basato su processi memorizzati o un ORM o una combinazione di entrambi
• Contro: Potrebbe essere necessario mantenere il livello del generatore di codice oltre a comprendere il codice generato

Answer 6

Hai dimenticato un'opzione significativa che merita una categoria a parte:un framework ibrido di mappatura dei dati come iBatis.

Sono rimasto soddisfatto di iBatis perché consente al codice OO di rimanere di natura OO e al database di rimanere di natura relazionale e risolve il disadattamento di impedenza aggiungendo una terza astrazione (lo strato di mappatura tra gli oggetti e le relazioni) che è responsabile di mappare i due, piuttosto che cercare di inserire forzatamente un paradigma nell’altro.