Devo prendere due diapositive per rispondere alla tua domanda. # 1 è "La logica aziendale dovrebbe essere eseguita nelle stored procedure, nel codice dell'applicazione o in entrambi?" # 2 riguarda la sfocatura delle linee tra codice e dati. La risposta alla prima domanda dipende dall'ambiente in cui lavori.

Usa stored procedure quando:

• Hai un team di database di crackerjack che progetta le tue applicazioni e gli sviluppatori di middle e front-end sono molto giovani
• La logica sarà condivisa da più applicazioni la cui unica comunanza è che usano lo stesso database.
• Il numero di chiamate tra l'applicazione e il database renderebbe il codice dell'applicazione troppo lento e una stored procedure sarebbe più veloce (e ne hai bisogno per essere così veloce).

Non utilizzare stored procedure quando:

• Il design delle tue applicazioni è fatto dai media
• Non vuoi essere legato a una determinata marca di database
• I tuoi DBA sono più simili agli amministratori di sistema che ai programmatori, incentrati sulla conservazione del database anziché sulla progettazione dell'applicazione
• Hai investito in un'architettura orientata ai servizi in cui tutto il tuo codice interagisce con un servizio che a sua volta chiama il database.
• La lingua della procedura memorizzata del database proviene dall'età della pietra (ad es. MySQL).
• Puoi ottenere le prestazioni necessarie senza di loro.

Riepilogo stored procedure

Negli ultimi anni c'è stato sicuramente un allontanamento dalle procedure archiviate. Fondamentalmente, metti la logica importante in cui le persone migliori possono prendersene cura.

Codice vs. dati

Implementare un Set come una definizione di ciò che appartiene a quell'insieme invece che come un contenitore che contiene oggetti usa il codice invece dei dati. Passare le funzioni ad altre funzioni le considera come dati. La modellizzazione del processo decisionale come una struttura ad albero tratta i dati dell'albero come il codice.

Esecuzione dell'elaborazione nel database rispetto a un servizio Web, rispetto al "back-end", al "front-end", rispetto ad AJAX nel browser di qualcuno è ancora solo il codice che opera sui dati, anche se in aree diverse di la tua infrastruttura. Direi piuttosto che offusca le responsabilità tra diversi livelli della tua architettura.

Mappatura relazionale oggetto (ORM)

Sì, l'obiettivo di ORM dovrebbe consentire di lavorare nella lingua scelta, dimenticando temporaneamente il formato di archiviazione. ORM ha successo quando semplifica i problemi di manipolazione delle astrazioni. Una procedura che avvolge una stored procedure è solo un altro livello di astrazione. Se non hai bisogno di pensare se sia supportato o meno da una stored procedure, allora ORM sta avendo successo.

Now technically none of this is business logic. You're not making any decisions - just performing a calculation and creating records.

Come pensi che questa sia la logica aziendale non ? Direi che molti sviluppatori concordano sul fatto che questa è la vera definizione della logica aziendale. Incapsula un comportamento dell'applicazione che esegue un servizio per un utente o un'attività per aumentare direttamente o indirettamente un obiettivo aziendale di creazione di fatture. Mentre la semplice ricerca di alcuni dati sui criteri può essere argomentata non è in realtà una logica aziendale, il calcolo dei nuovi dati lo è certamente.

Quindi, dove entrano in gioco le stored procedure? Questa risposta non è chiara e non tutti sono d'accordo sul ruolo appropriato delle stored procedure. Non tutti sono nemmeno d'accordo sul fatto che le stored procedure dovrebbero mai esistere, sostenendo che fondamentalmente la linea di confine tra il livello dei dati e la logica aziendale dovrebbe idealmente esistere solo nel livello dell'applicazione. Altri prendono l'altro approccio di linea dura che le procedure memorizzate dovrebbero contenere la maggior parte della logica di business possibile e il livello dell'applicazione dovrebbe essere sottile.

C'è sempre una via di mezzo quando si tratta di stored procedure. Per attività intensive o impegnative in termini di tempo in cui è possibile ottenere un significativo vantaggio in termini di prestazioni unendo record ed eseguendo calcoli sul livello del database (ad esempio analitica, data mart, report, ecc.), È possibile fornire un argomento valido per l'importanza e ruolo delle stored procedure in un'applicazione.

Le stored procedure sono luoghi orribili per qualsiasi tipo di logica aziendale e, se un ORM maschera una stored procedure, questo è semplicemente per comodità.

L'intero codice ipotetico sopra riportato può essere eseguito senza stored procedure e dovrebbe essere. Un database in termini di un ORM dovrebbe significare che il database non ha più importanza. Diventa solo un livello di persistenza. Una procedura memorizzata dovrebbe essere eseguita solo se non ci sono altre alternative a un problema specifico.

Questo è ovviamente un approccio rigoroso, ma la mia esperienza nel provare a lavorare con entrambi non ha fatto altro che frustrarmi. Ho finito per spostare tutta la logica sul mio codice. Le stored procedure proteggono dal modello di dati sottostante, ORM espone il modello all'utente. Penso che siano due modi di lavorare fondamentalmente diversi.

È anche più facile e meno ambiguo quando si prende un approccio più rigoroso al problema.

In base al tuo commento:

because in ORMs, stored procedures often look like functions the same as they would as if the functionality was written in code. Hence my comment about the lines being blurred because if you treat it as a black box, there's suddenly no difference

allora sì, se qualcun altro ha dovuto scrivere la parte di accesso al database della tua applicazione e tutto ciò che avevi a che fare era il risultato, sono gli stessi. Mi interesserebbe solo se l'altro dev ha utilizzato un ORM o un Proc. Memorizzato se ho bisogno di lavorare con quel codice. La manutenzione è un problema, oltre a sapere cosa sta succedendo nella scatola nera.

Con un ORM, sai dove si trova il codice. Se usi una stored procedure, non so se stai manipolando i risultati nel proc stesso o se il tuo livello di accesso ai dati sta facendo qualcos'altro con esso.

ORM's blur the line between code and data

Direi codice e database E usare la parola "sfocatura" ha una connotazione negativa qui. Come se non sapessi cosa sta succedendo. L'offuscamento mi infastidisce; metterlo in una scatola nera è l'opposto di una distrazione (supponendo che so cosa è stato messo nella scatola nera che se questo è il punto della questione è solo una questione di capire il codice utilizzato). Fuori dal sito, fuori di testa.