Le stored procedure violano la separazione a tre livelli?

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

L'idea alla base di un'applicazione multilivello è semplicemente la suddivisione in parti che incapsulano determinati tipi di elaborazione (archiviazione, logica aziendale, presentazione) e comunicano tra loro utilizzando interfacce ben definite. Proprio 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 due elementi è la necessità di cure, disciplina e comprensione dei compromessi coinvolti.

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

• Livello dati: consiste in tabelle di database accessibili tramite le quattro operazioni di tabella standard ( INSERT , UPDATE , DELETE e SELECT ).
• Livello di logica: è costituito da stored procedure che implementano solo la business logic e accedono al livello dati utilizzando solo i metodi descritti sopra.
• Livello presentazione: consiste in un server Web che esegue un codice che accede al livello logico effettuando solo chiamate di stored procedure.

Questo è un modello perfettamente accettabile, ma ha alcuni compromessi. La logica aziendale è implementata in modo tale da consentire un accesso rapido e facile al livello dati e consentire di fare cose che dovrebbero essere eseguite "nel modo più duro" da un livello logico esterno al database. Ciò che rinunciamo è la capacità di spostare facilmente uno o l'altro livello di tecnologia e un'implementazione spensierata (vale a dire, bisogna stare attenti che i livelli non utilizzino strutture disponibili nel database ma al di fuori delle interfacce definite) .

Indipendentemente dal fatto che questo tipo di cose e i compromessi che porta siano accettabili in una determinata situazione è qualcosa che tu e i tuoi colleghi dovete determinare usando il vostro giudizio.

Le stored procedure 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 stored procedure. Puoi limitare i tuoi SP a soddisfare le esigenze del tuo livello dati, mantenendo la logica dell'applicazione nel livello applicazione della tua architettura.

C'è una eccezione rara ma importante alla regola della separazione, quando hai bisogno di stored procedure (in particolare, un gruppo di trigger) per contenere la logica di business. Questo accade quando l'applicazione deve produrre molte aggregazioni di dati al volo che toccano milioni di righe. In casi come questi, i trigger possono essere impostati per mantenere i dati pre-aggregati per l'utilizzo del livello aziendale. Questo dovrebbe essere fatto solo in situazioni in cui senza pre-aggregazione la tua applicazione sarebbe inaccettabilmente lenta.

Breve riassunto: dipende davvero dall'utilizzo delle stored procedure e dei 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 presentazione o livello dei servizi utente: consente all'utente di accedere all'applicazione.
• Livello intermedio o livello dei servizi aziendali: è costituito da regole aziendali e dati.
• Il livello dati o livello dei servizi dati - interagisce con i dati permanenti solitamente memorizzati in un database o in una memoria permanente.

In genere per l'architettura data, il livello il livello intermedio o di servizi aziendali è costituito da regole aziendali e dati. Tuttavia, a volte fa una grande differenza spostare le pesanti operazioni di base e / o le regole dei dati da eseguire in livello dati - tramite un insieme di stored procedure.

I vantaggi dei design a tre livelli sono:

During an application's life cycle, the three-tier approach provides benefits such as reusability, flexibility, manageability, maintainability, and scalability. You can share and reuse the components and services you create, and you can distribute them across a network of computers as needed. You can divide large and complex projects into simpler projects and assign them to different programmers or programming teams. You can also deploy components and services on a server to help keep up with changes, and you can redeploy them as growth of the application's user base, data, and transaction volume increases.

Quindi, è davvero un approccio basato su un caso che ha dei compromessi in sé. Tuttavia, le linee guida sulla progettazione Microsoft del modello di architettura a tre livelli consiglia di mantenere la logica aziendale nel livello intermedio.

I consigli di Atwood del 2004 sono ancora vivi, ma ora abbiamo anche il vantaggio di ORM.

link

Stored Procedures should be considered database assembly language: for use in only the most performance critical situations. There are plenty of ways to design a solid, high performing data access layer without resorting to Stored Procedures; you'll realize a lot of benefits if you stick with parameterized SQL and a single coherent development environment.

Livello in realtà significa macchina diversa, livello significa separazione logica diversa. Con le stored procedure si dispone del livello dati e (almeno in parte) del livello della business logic nello stesso livello. Mettere la logica aziendale nelle stored procedure viola l'architettura a 3 stadi ma è discutibile se viola un'architettura a 3 strati; una cosa certa è che sicuramente non è un buon esempio di separazione delle preoccupazioni.

A layer is a logical structuring mechanism for the elements that make up your software solution; a tier is a physical structuring mechanism for the system infrastructure. (Reference)

Secondo me ci sono due problemi principali nella creazione di business logic 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, librerie e framework eccellenti .

2. Scalabilità orizzontale: l'unico modo per ridimensionare il sistema è cambiando il server fisico su cui il database è più potente, che è piuttosto costoso (un server con 64 GB di RAM); i database relazionali sono in scala orizzontale molto cattivi e anche a maggiori costi. Mentre, con la logica di business nel server OO-build, è possibile scalare in orizzontale piuttosto bene mettendo il server su molti nodi (in Java molti server di applicazioni supportano questo).

Abbiamo avuto questo dibattito nel nostro ufficio alcune volte, stavo favorendo lo sviluppo del database, ho seguito la sua opinione

1. Se stai usando il Database Oracle, dovresti utilizzare PL / SQL il più possibile, perché di sicuro le aziende che investono rimarranno fedele a Oracle per almeno 10 anni da oggi. Mentre nelle applicazioni di ieri stavi usando Oracle Forms, oggi. Nets Web Form, quindi MVC, dopodiché useresti angularjs e avrai solo bisogno di apis restfull. Se la logica massima è nel database, è possibile migrare facilmente alle nuove tecnologie front-end.
2. Lo sviluppo del database è molto veloce e molto efficiente. 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 le utilità per convertire direttamente le procedure del database in Api di ripristino completo.

L'argomento più strong che gli sviluppatori di applicazioni danno è che la logica di business dovrebbe essere indipendente dal database in modo da poter facilmente cambiare il database. Penso che se un'azienda sta utilizzando Oracle perché passerà ad altre tecnologie invece le probabilità di ottenere una logica applicativa obsoleta sono più prevedibili. Il problema è in gran parte nuovo talento della risorsa del database è carente, per lo più i ragazzi iniziano a siti Web semplici in cui utilizzano mysql o sqlserver. Questi ragazzi diventano quindi lead senior e hanno un attaccamento emotivo con il livello dell'applicazione :) non vogliono neppure capire o discutere.