Le procedure memorizzate violano la separazione a tre livelli?

Alcuni miei colleghi mi hanno detto che avere la logica aziendale nelle procedure memorizzate nel database viola l'architettura di separazione a tre livelli, poiché il database appartiene al livello dati mentre le procedure memorizzate sono logiche aziendali.

Penso che il mondo sarebbe un posto molto triste senza procedure memorizzate.

In realtà violano la separazione a tre livelli?

I tuoi colleghi stanno fondendo l'architettura con l'implementazione.

L'idea alla base di un'applicazione a più livelli è semplicemente che è suddivisa in parti che incapsulano determinati tipi di elaborazione (archiviazione, logica aziendale, presentazione) e comunicano tra loro utilizzando interfacce ben definite. Così come è possibile fare con successo cose che assomigliano alla programmazione orientata agli oggetti in linguaggi non orientati agli oggetti, è possibile fare lo stesso con più livelli all'interno di un ambiente, come un server di database. Ciò che ha in comune uno di questi successi è la necessità di cure, disciplina e comprensione dei compromessi coinvolti.

Diamo un'occhiata a un'applicazione a tre livelli in cui due dei livelli sono stati implementati su un database:

• Dati Livello: Consiste di tabelle di database a cui si accede utilizzando le quattro operazioni di tabella standard ( INSERT, UPDATE, DELETEe SELECT).
• Livello logico: è costituito da procedure memorizzate che implementano solo la logica aziendale e accedono al livello dati utilizzando solo i metodi descritti sopra.
• Livello di presentazione: è costituito da un server Web che esegue codice che accede al livello di logica effettuando solo chiamate di procedure memorizzate.

Questo è un modello perfettamente accettabile, ma presenta alcuni compromessi. La logica di business è implementata in modo da consentire un accesso rapido e facile al livello dati e può consentire di fare cose che dovrebbero essere fatte "nel modo più duro" da un livello logico esterno al database. Ciò a cui rinunciamo è la capacità di spostare facilmente entrambi i livelli su qualche altra tecnologia e un'implementazione spensierata (vale a dire, devi fare molta attenzione che i livelli non utilizzino le strutture disponibili nel database ma al di fuori delle loro interfacce definite) .

Se questo tipo di cose e i compromessi che comporta sono accettabili in una determinata situazione è qualcosa che tu e i tuoi colleghi dovete determinare usando il vostro giudizio.

Le procedure memorizzate sono abbastanza potenti da consentire di codificare una violazione della separazione a tre livelli portando la logica aziendale nel livello RDBMS. Tuttavia, questa è la tua decisione, non un difetto intrinseco delle procedure memorizzate. Puoi limitare i tuoi SP a soddisfare le esigenze del tuo livello dati, mantenendo la logica dell'applicazione nel livello applicazione della tua architettura.

Esiste un'eccezione rara ma importante alla regola della separazione, quando sono necessarie procedure memorizzate (in particolare un gruppo di trigger) per contenere la logica aziendale. Ciò accade quando l'applicazione deve produrre molte aggregazioni di dati al volo che toccano milioni di righe. In casi del genere, è possibile impostare i trigger per mantenere i dati pre-aggregati per l'uso del livello aziendale. Questo dovrebbe essere fatto solo in situazioni in cui senza pre-aggregazione l'applicazione sarebbe inaccettabilmente lenta.

I consigli di Atwood del 2004 suonano ancora veri oggi, solo ora abbiamo anche il vantaggio di ORM.

http://blog.codinghorror.com/who-needs-stored-procedures-anyways/

Le Stored procedure devono essere considerate come linguaggio di assemblaggio del database: per l'uso solo nelle situazioni più critiche per le prestazioni. Esistono molti modi per progettare un livello di accesso ai dati solido e ad alte prestazioni senza ricorrere a Stored procedure; otterrai molti vantaggi se rimani con SQL parametrizzato e un unico ambiente di sviluppo coerente.

Breve riepilogo: dipende molto dall'utilizzo delle procedure memorizzate e dai requisiti aziendali.

Esistono numerosi progetti che utilizzano un'architettura a tre livelli e, a seconda della natura dei requisiti aziendali, potrebbe essere necessario spostare alcune operazioni su un livello dati.

Parlando di terminologia, in generale questi livelli sono descritti come:

• Il livello di presentazione o il livello dei servizi utente: consente a un utente di accedere all'applicazione.
• Il livello intermedio , o livello dei servizi aziendali, è costituito da regole aziendali e di dati.
• Il livello dati o livello servizi dati interagisce con i dati persistenti generalmente archiviati in un database o in una memoria permanente.

Di solito per l'architettura data, il livello intermedio o il livello dei servizi aziendali, è costituito da regole aziendali e di dati. Tuttavia, a volte fa una grande differenza spostare le operazioni di set di base pesanti e / o le regole dei dati da eseguire nel livello di dati , attraverso una serie di procedure memorizzate.

I vantaggi dei design a tre livelli sono:

Durante il ciclo di vita di un'applicazione, l'approccio a tre livelli offre vantaggi come riusabilità, flessibilità, gestibilità, manutenibilità e scalabilità. È possibile condividere e riutilizzare i componenti e i servizi creati e distribuirli su una rete di computer in base alle esigenze. Puoi dividere progetti grandi e complessi in progetti più semplici e assegnarli a programmatori o team di programmazione diversi. È inoltre possibile distribuire componenti e servizi su un server per tenere il passo con le modifiche e ridistribuirle all'aumentare della base di utenti dell'applicazione, dei dati e del volume delle transazioni.

Pertanto, si tratta in realtà di un approccio basato sui casi che ha dei compromessi in sé. Tuttavia, le linee guida di progettazione Microsoft del modello di architettura a tre livelli raccomandano di mantenere la logica di business di livello intermedio.

Livello in realtà significa macchina diversa, strato significa diversa separazione logica. Con le procedure memorizzate, il livello dati e (almeno parte) del livello di logica aziendale si trovano nello stesso livello. Mettere la logica di business nelle procedure memorizzate viola l'architettura a 3 stanchi ma è discutibile se viola un'architettura a 3 livelli; una cosa certa è che non è certo un buon esempio di separazione delle preoccupazioni.

Un livello è un meccanismo di strutturazione logica per gli elementi che compongono la soluzione software; un livello è un meccanismo di strutturazione fisica per l'infrastruttura di sistema. ( Riferimento )

A mio avviso, ci sono due problemi principali con la costruzione della logica aziendale nel database:

1. Codice e librerie: troverai meno programmatori in grado di programmare in SQL, PL / SQL, TSQL ecc. Rispetto a C #, Java ecc. I linguaggi di programmazione hanno anche il vantaggio di grandi IDE, ottime librerie e framework.

2. Scalabilità orizzontale: l'unico modo per scalare il sistema è cambiando il server fisico su cui il database è più potente, che è piuttosto costoso (un server con 64 GB di RAM); database relazionali scalabili orizzontalmente molto male, e anche a spese maggiori. Mentre, con la logica aziendale nel server costruito su OO, puoi ridimensionare orizzontalmente piuttosto bene posizionando il server su molti nodi (in Java molti server applicazioni lo supportano).

Abbiamo avuto questo dibattito nel nostro ufficio qualche volta fa, stavo favorendo lo sviluppo di database, ne ho una visione successiva

1. Se stai utilizzando Oracle Database, dovresti utilizzare PL / SQL il più possibile, perché sicuramente le aziende che investono si attaccheranno all'oracolo almeno tra 10 anni. Mentre ieri nelle applicazioni utilizzavi Oracle Forms, oggi i moduli Web .net, poi MVC, poi domani userai angularjs e avrai solo bisogno di riposanti API. Se nel database è presente la massima logica, è possibile migrare facilmente alle nuove tecnologie front-end.
2. Lo sviluppo del database è molto veloce e molto efficiente in termini di prestazioni. Solo per darti una prospettiva. Nel nostro progetto c'erano 7 sviluppatori di applicazioni e uno sviluppatore di database e l'80% della logica era nel database.
3. Se si utilizza Oracle è possibile utilizzare i programmi di utilità per convertire direttamente le procedure del database in Res full Api.

L'argomento più forte che gli sviluppatori di applicazioni sostengono che la logica aziendale dovrebbe essere indipendente dal database in modo da poterlo modificare facilmente. Penso che se un'azienda sta utilizzando l'oracolo perché passeranno ad altre tecnologie, invece sono più attese le possibilità di rendere obsoleta la logica dell'applicazione. Il problema è che mancano soprattutto i nuovi talenti della risorsa del database, per lo più i ragazzi iniziano a creare semplici siti Web in cui utilizzano mysql o sqlserver. Questi ragazzi diventano quindi senior e hanno un attaccamento emotivo con il livello applicativo :) non vogliono nemmeno capire o discutere.