Logica aziendale: database o livello applicazione

Question

La domanda secolare. Dove dovresti inserire la tua logica aziendale, nel database come stored procedure (o pacchetti) o nell'applicazione / livello intermedio? E, soprattutto, perché?

Supponiamo che l'indipendenza del database non sia un obiettivo.

Answer 1

Metti abbastanza della logica aziendale nel database per assicurarti che i dati siano coerenti e corretti.

Ma non temere di dover duplicare parte di questa logica ad un altro livello per migliorare l'esperienza dell'utente.

Answer 2

La manutenibilità del codice è sempre una grande preoccupazione nel determinare dove dovrebbe andare la logica aziendale.

Gli strumenti di debug integrati e gli IDE più potenti in genere semplificano il mantenimento del codice di livello intermedio rispetto allo stesso codice in una procedura memorizzata. A meno che non ci sia una vera ragione altrimenti, dovresti iniziare con la logica aziendale nel tuo livello intermedio / applicazione e non nelle procedure memorizzate.

Tuttavia, quando si tratta di reportistica e data mining / ricerca, le procedure memorizzate possono spesso essere una scelta migliore. Questo grazie alla potenza delle capacità di aggregazione / filtro dei database e al fatto che continui a elaborare molto da vicino la fonte dei dati. Ma questo potrebbe non essere ciò che la maggior parte considera la classica logica aziendale comunque.

Answer 3

Per casi molto semplici è possibile inserire la logica aziendale nelle procedure memorizzate. Di solito anche i casi semplici tendono a complicarsi nel tempo. Ecco i motivi per cui non inserisco la logica aziendale nel database:

Mettere la logica di business nel database la accoppia strettamente all'implementazione tecnica del database. La modifica di una tabella comporta la modifica di molte procedure memorizzate, causando molti bug e test aggiuntivi.

Di solito l'interfaccia utente dipende dalla logica aziendale per cose come la convalida. L'inserimento di queste cose nel database provocherà uno stretto accoppiamento tra il database e l'interfaccia utente o in diversi casi duplicherà la logica di convalida tra questi due.

Sarà difficile far funzionare più applicazioni sullo stesso database. Le modifiche per una domanda causeranno la rottura di altre. Questo può rapidamente trasformarsi in un incubo di manutenzione. Quindi non si ridimensiona davvero.

Più praticamente SQL non è un buon linguaggio per implementare la logica di business in modo comprensibile. SQL è ottimo per operazioni basate su set ma manca costrutti per la programmazione "in generale" è difficile mantenere grandi quantità di procedure memorizzate. Le lingue OO moderne sono più adatte e più flessibili per questo.

Questo non significa che non puoi usare i processi e le viste memorizzati. Penso che a volte sia una buona idea mettere un ulteriore livello di stored procedure e viste tra le tabelle e le applicazioni per separare i due. In questo modo è possibile modificare il layout del database senza modificare l'interfaccia esterna che consente di eseguire il refactoring del database in modo indipendente.

Answer 4

Dipende da te, purché tu sia coerente .

Un buon motivo per inserirlo nel tuo livello di database: se sei abbastanza sicuro che i tuoi clienti non cambieranno mai il loro back-end del database.

Un buon motivo per inserirlo nel livello applicazione: se si stanno prendendo di mira più tecnologie di persistenza per la propria applicazione.

Dovresti anche tenere conto delle competenze chiave. I tuoi sviluppatori sono principalmente sviluppatori a livello di applicazione o sono principalmente tipi DBA?

Answer 5

Sebbene ci siano certamente dei vantaggi nell'avere la logica aziendale a livello di applicazione, vorrei sottolineare che le lingue / i framework sembrano cambiare più frequentemente dei database.

Alcuni dei sistemi da me supportati hanno attraversato le seguenti interfacce utente negli ultimi 10-15 anni: Oracle Forms / Visual Basic / Perl CGI / ASP / Java Servlet. L'unica cosa che non è cambiata: il database relazionale e le procedure memorizzate.

Answer 6

Anche se non esiste una risposta corretta, dipende dal progetto in questione, consiglierei l'approccio sostenuto in " Domain Driven Desig n " di Eric Evans. In questo approccio la logica aziendale è isolata nel proprio livello - il livello di dominio - che si trova sopra il / i livello / i dell'infrastruttura - che potrebbe includere il codice del database e sotto il livello dell'applicazione, che invia le richieste nel livello di dominio per la realizzazione e ascolta la conferma del loro completamento, guidando efficacemente l'applicazione.

In questo modo, la logica di business viene catturata in un modello che può essere discusso con coloro che comprendono il business oltre a problemi tecnici, e dovrebbe rendere più semplice isolare i cambiamenti nelle stesse regole di business, i problemi di implementazione tecnica e il flusso dell'applicazione che interagisce con il modello di business (dominio).

Ti consiglio di leggere il libro sopra se ne hai la possibilità, in quanto è abbastanza bravo a spiegare come questo puro ideale possa effettivamente essere approssimato nel mondo reale del codice reale e dei progetti.

Answer 7

L'indipendenza del database, che in questo caso l'interrogante esclude come considerazione, è l'argomento più forte per eliminare la logica dal database. L'argomento più forte per l'indipendenza del database è la capacità di vendere software alle aziende con le loro preferenze per un back-end del database.

Pertanto, considererei l'argomento principale per estrarre le procedure memorizzate dal database solo come commerciale, non tecnico. Potrebbero esserci motivi tecnici ma ci sono anche motivi tecnici per mantenerlo lì - prestazioni, integrità e la capacità di consentire ad più applicazioni di utilizzare la stessa API, ad esempio.

L'utilizzo o meno di SP è fortemente influenzato dal database che si intende utilizzare. Se si prende in considerazione l'indipendenza del database, si avranno esperienze molto diverse nell'uso di T-SQL o PL / SQL.

Se si utilizza Oracle per sviluppare un'applicazione, PL / SQL è una scelta ovvia come linguaggio. È strettamente associato ai dati, continuamente migliorato in ogni caso e qualsiasi strumento di sviluppo decente integrerà lo sviluppo PL / SQL con CVS o Subversion o somesuch.

L'ambiente di sviluppo Application Express basato sul Web di Oracle è persino costruito al 100% con PL / SQL.

Answer 8

Tutto ciò che influisce sull'integrità dei dati deve essere messo a livello di database. Altre cose oltre all'interfaccia utente spesso inseriscono i dati, aggiornano o eliminano i dati dal database tra cui importazioni, aggiornamenti di massa per modificare uno schema tariffario, hot fix, ecc. Se è necessario assicurarsi che le regole vengano sempre seguite, impostare la logica sui valori predefiniti e si innesca.

Questo non vuol dire che non è una buona idea averlo anche nell'interfaccia utente (perché preoccuparsi di inviare informazioni che il database non accetterà), ma ignorare queste cose nel database significa corteggiare il disastro .

Answer 9

Se hai bisogno di indipendenza dal database, probabilmente vorrai mettere tutta la tua logica aziendale nel livello dell'applicazione poiché gli standard disponibili nel livello applicazione sono molto più prevalenti di quelli disponibili per il livello database.

Tuttavia, se l'indipendenza del database non è il fattore n. 1 e il set di competenze del tuo team include competenze di database forti, l'inserimento della logica di business nel database potrebbe rivelarsi la soluzione migliore. Puoi fare in modo che le persone che eseguono le applicazioni eseguano operazioni specifiche dell'applicazione e quelle del database assicurandosi che tutte le query siano valide.

Naturalmente, c'è una grande differenza tra la capacità di mettere insieme un'istruzione SQL e di avere "buone capacità di database" - se la tua squadra è più vicina alla prima rispetto alla seconda, inserisci la logica nell'applicazione usando uno degli ibernati di questo mondo (o cambia la tua squadra!).

Nella mia esperienza, in un ambiente Enterprise avrai un unico database di destinazione e competenze in questo settore - in questo caso metti tutto il possibile nel database. Se sei interessato alla vendita di software, i costi di licenza del database renderanno l'indipendenza del database il fattore più importante e implementerai tutto ciò che puoi nel livello dell'applicazione.

Spero che sia d'aiuto.

Answer 10

Al giorno d'oggi è possibile inviare per sovvertire il codice proc memorizzato e eseguire il debug di questo codice con un buon supporto degli strumenti.

Se si utilizzano proc memorizzati che combinano istruzioni sql, è possibile ridurre la quantità di traffico dati tra l'applicazione e il database e ridurre il numero di chiamate al database e ottenere grandi guadagni in termini di prestazioni.

Una volta che abbiamo iniziato a costruire in C # abbiamo preso la decisione di non utilizzare i proc memorizzati ma ora stiamo spostando sempre più codice sui proc memorizzati. Soprattutto elaborazione batch.

Tuttavia, non utilizzare i trigger, utilizzare proc memorizzati o pacchetti migliori. I trigger diminuiscono la manutenibilità.

Answer 11

Inserendo il codice nel livello dell'applicazione si otterrà un'applicazione indipendente dal DB.

A volte è meglio usare le procedure memorizzate per motivi di prestazioni.

(come al solito) dipende dai requisiti dell'applicazione.

Answer 12

L'unica cosa che va in un database sono i dati.

Le procedure memorizzate sono un incubo per la manutenzione. Non sono dati e non appartengono al database. Il coordinamento infinito tra sviluppatori e DBA è poco più che attrito organizzativo.

È difficile mantenere un buon controllo della versione sulle procedure memorizzate. Il codice esterno al database è davvero facile da installare: quando pensi di avere la versione sbagliata, esegui semplicemente un SVN UP (forse un'installazione) e la tua applicazione torna a uno stato noto. Hai variabili d'ambiente, collegamenti alle directory e molto controllo ambientale sull'applicazione.

È possibile, con semplici manipolazioni PATH , disporre di software varianti disponibili per diverse situazioni (formazione, test, QA, produzione, miglioramenti specifici del cliente, ecc. ecc.)

Il codice all'interno del database, tuttavia, è molto più difficile da gestire. Non esiste un ambiente adeguato - nessun "PATH", collegamenti a directory o altre variabili di ambiente - per fornire qualsiasi controllo utilizzabile su quale software viene utilizzato; hai un set permanente di software applicativo associato a livello globale bloccato nel database, sposato con i dati.

I trigger sono anche peggio. Sono sia un incubo di manutenzione che un debug. Non vedo quale problema risolvono; sembrano essere un modo per aggirare le applicazioni mal progettate in cui qualcuno non potrebbe essere disturbato a usare correttamente le classi (o le librerie di funzioni) disponibili.

Mentre alcune persone trovano convincente l'argomento delle prestazioni, non ho ancora visto abbastanza dati di riferimento per convincermi che le procedure memorizzate sono così veloci. Ognuno ha un aneddoto, ma nessuno ha un codice side-by-side in cui gli algoritmi sono più o meno gli stessi.

[Negli esempi che ho visto, la vecchia applicazione era un pasticcio mal progettato; quando sono state scritte le stored procedure, l'applicazione è stata riprogettata. Penso che la modifica del design abbia avuto un impatto maggiore rispetto alla modifica della piattaforma.]

Answer 13

La logica aziendale deve essere posizionata nell'applicazione / livello intermedio come prima scelta. In questo modo può essere espresso sotto forma di un modello di dominio, essere posizionato nel controllo del codice sorgente, essere suddiviso o combinato con il codice correlato (refactored), ecc. Inoltre, offre una certa indipendenza dal fornitore del database.

I linguaggi orientati agli oggetti sono anche molto più espressivi delle procedure memorizzate, consentendo di descrivere meglio e più facilmente nel codice cosa dovrebbe accadere.

Le uniche buone ragioni per inserire il codice nelle stored procedure sono: se ciò produce un vantaggio significativo e necessario in termini di prestazioni o se lo stesso codice aziendale deve essere eseguito da più piattaforme (Java, C #, PHP). Anche quando si utilizzano più piattaforme, esistono alternative come i servizi Web che potrebbero essere più adatte alla condivisione delle funzionalità.

Answer 14

La risposta nella mia esperienza sta da qualche parte in uno spettro di valori solitamente determinati da dove risiedono le competenze della tua organizzazione.

Il DBMS è una bestia molto potente, il che significa che un trattamento adeguato o improprio porterà grandi benefici o un grande pericolo. Purtroppo, in troppe organizzazioni, l'attenzione principale è rivolta allo staff di programmazione; le competenze di dbms, in particolare le capacità di sviluppo delle query (al contrario di quelle amministrative) vengono trascurate. Il che è aggravato dal fatto che probabilmente manca anche la capacità di valutare le abilità dei dbms.

E ci sono pochi programmatori che comprendono sufficientemente ciò che non capiscono sui database.

Da qui la popolarità di concetti non ottimali, come Active Records e LINQ (per gettare alcuni pregiudizi ovvi). Ma sono probabilmente la migliore risposta per tali organizzazioni.

Tuttavia, si noti che le organizzazioni su larga scala tendono a prestare molta più attenzione all'utilizzo efficace dell'archivio dati.

Answer 15

Non esiste una risposta corretta autonoma a questa domanda. Dipende dai requisiti della tua app, dalle preferenze e dalle competenze dei tuoi sviluppatori e dalla fase della luna.

Answer 16

La logica aziendale deve essere inserita nel livello applicazione e non nel database. Il motivo è che una stored procedure di database dipende sempre dal prodotto di database utilizzato. Questo rompe uno dei vantaggi del modello a tre livelli. Non è possibile passare facilmente a un altro database a meno che non si fornisca una stored procedure aggiuntiva per questo prodotto di database. d'altra parte a volte, ha senso inserire la logica in una procedura memorizzata per l'ottimizzazione delle prestazioni.

Quello che voglio dire è che la logica aziendale deve essere inserita nel livello dell'applicazione, ma ci sono eccezioni (principalmente motivi di prestazioni)

Answer 17

I 'livelli' dell'applicazione bussiness sono:

1. Interfaccia utente

Questo implementa la visione dell'utente di lavoro h (is / er). Usa termini a cui l'utente ha familiarità.

2. Processing

Qui è dove avvengono i calcoli e la manipolazione dei dati. Qualsiasi logica aziendale che comporta la modifica dei dati viene implementata qui.

3. Database

Potrebbe essere: un database sequenziale normalizzato (i DBMS standard basati su SQL); un database OO, che memorizza oggetti che avvolgono i dati aziendali; ecc.

Cosa va dove

Per arrivare ai livelli precedenti devi fare le analisi e la progettazione necessarie. Ciò indicherebbe dove sarebbe meglio implementare la logica aziendale: le regole di integrità dei dati e i problemi di concorrenza / in tempo reale relativi agli aggiornamenti dei dati sarebbero normalmente implementati il ??più vicino possibile ai dati, lo stesso dei campi calcolati, e questo è un buon puntatore alle stored procedure / trigger, in cui l'integrità dei dati e il controllo delle transazioni sono assolutamente necessari.

Le regole aziendali che implicano il significato e l'uso dei dati verrebbero per la maggior parte implementate nel livello Elaborazione, ma apparirebbero anche nell'interfaccia utente come flusso di lavoro dell'utente, collegando i vari processi in una sequenza che riflette il lavoro dell'utente.

Answer 18

IMHO. ci sono due preoccupazioni contrastanti nel decidere dove va la logica aziendale in un'app basata su database relazionale:

• manutenibilità
• affidabilità

Re. manutenibilità: & nbsp; Per consentire uno sviluppo futuro efficiente, la logica di business appartiene alla parte della tua applicazione più facile da eseguire il debug e il controllo della versione.

Re. affidabilità: & nbsp; Quando esiste un rischio significativo di incoerenza, la logica aziendale appartiene al livello del database. & nbsp; I database relazionali possono essere progettati per verificare la presenza di vincoli sui dati, ad es. non consentire valori NULL in colonne specifiche, ecc. & nbsp; Quando si verifica uno scenario nella progettazione dell'applicazione in cui alcuni dati devono trovarsi in uno stato specifico che è troppo complesso per esprimere con questi semplici vincoli, può avere senso utilizzare un trigger o qualcosa di simile nel livello del database.

I trigger sono un problema da tenere aggiornati, soprattutto quando la tua app dovrebbe essere eseguita su sistemi client a cui non hai nemmeno accesso. & nbsp; Ma ciò non significa che sia impossibile tenerne traccia o aggiornarli. & nbsp; Le argomentazioni di S.Lott nella sua risposta secondo cui è una sofferenza e una seccatura sono completamente valide, lo ripeterò e ci sono stato anche io. & nbsp; Ma se tieni a mente queste limitazioni quando progetti per la prima volta il tuo livello di dati e ti astieni dall'utilizzare i trigger e le funzioni per tutto tranne che per le necessità assolute è gestibile.

Nella nostra applicazione, la maggior parte della logica aziendale è contenuta nel livello del modello dell'applicazione, ad es. una fattura sa come inizializzarsi da un determinato ordine cliente. & nbsp; Quando un gruppo di cose diverse viene modificato in sequenza per un insieme complesso di modifiche come questo, le arrotoliamo in una transazione per mantenere la coerenza, invece di optare per una procedura memorizzata. & nbsp; Il calcolo dei totali ecc. Viene eseguito con metodi nel livello del modello. & nbsp; Ma quando dobbiamo denormalizzare qualcosa per le prestazioni o inserire dati in una tabella di "modifiche" utilizzata da tutti i client per capire quali oggetti devono scadere nella cache della sessione, utilizziamo trigger / funzioni nel livello del database per inserire un nuova riga e invia una notifica (Postgres ascolta / notifica roba) da questo trigger.

Dopo avere la nostra app sul campo per circa un anno, utilizzata da centinaia di clienti ogni giorno, l'unica cosa che cambierei se dovessimo iniziare da zero sarebbe progettare il nostro sistema per la creazione di funzioni di database (o procedure memorizzate , comunque tu voglia chiamarli) con il versioning e gli aggiornamenti in mente fin dall'inizio.

Per fortuna, abbiamo un sistema in atto per tenere traccia delle versioni dello schema, quindi abbiamo costruito qualcosa sopra per occuparci di sostituire le funzioni del database. & nbsp; Ci farebbe risparmiare un po 'di tempo ora se avessimo considerato la necessità di sostituirli dall'inizio.

---

Ovviamente, tutto cambia quando esci dal regno di RDBMS in sistemi di archiviazione di tuple come Amazon SimpleDB e Google BigTable. & nbsp; Ma questa è una storia diversa :)

Answer 19

Mettiamo molta logica di business nelle procedure memorizzate - non è l'ideale, ma abbastanza spesso è un buon equilibrio tra prestazioni e affidabilità.

E sappiamo dove si trova senza dover cercare tra acri di soluzioni e codebase!

Answer 20

La scalabilità è anche un fattore molto importante per mettere in pratica la logica di business nel livello centrale o di app piuttosto che nel livello di database. Dovrebbe essere chiaro che DatabaseLayer serve solo per interagire con il database senza manipolare quale viene restituito al o dal database.

Answer 21

Ricordo di aver letto un articolo da qualche parte che sottolineava che abbastanza bene tutto può essere, a un certo livello, parte della logica aziendale, e quindi la domanda non ha senso.

Penso che l'esempio fornito sia stato la visualizzazione di una fattura sullo schermo. La decisione di contrassegnarne una in ritardo in rosso è una decisione commerciale ...

Answer 22

È un continuum. IMHO il fattore più importante è la velocità. Come si fa a far funzionare questa ventosa il più rapidamente possibile e allo stesso tempo aderire a buoni inquilini della programmazione come manutenibilità, prestazioni, scalabilità, sicurezza, affidabilità ecc. Spesso SQL è il modo più conciso per esprimere qualcosa e sembra essere il più performante molte volte, tranne per le operazioni sulle stringhe ecc., ma è qui che i tuoi Proc CLR possono aiutarti. La mia convinzione è quella di cospargere liberamente la logica di business ovunque tu pensi che sia meglio per l'impresa a portata di mano. Se hai un sacco di sviluppatori di applicazioni che si cagano i pantaloni quando guardano SQL, lascia che usino la logica della loro app. Se vuoi davvero creare un'applicazione ad alte prestazioni con set di dati di grandi dimensioni, inserisci quanta più logica possibile nel DB. Attiva i tuoi DBA e offri agli sviluppatori la massima libertà sui loro database Dev. Non esiste una risposta o lo strumento migliore per il lavoro. Hai più strumenti, quindi diventa esperto a tutti i livelli dell'applicazione e scoprirai presto che stai spendendo molto più tempo a scrivere un codice SQL espressivo e discreto laddove garantito e ad utilizzare il livello applicazione altre volte. Per me, in definitiva, ridurre il numero di righe di codice è ciò che porta alla semplicità. Abbiamo appena convertito un'applicazione sql rich con solo 2500 righe di codice app e 1000 righe di SQL in un modello di dominio che ora ha 15500 righe di codice app e 2500 righe di SQL per ottenere ciò che ha fatto la precedente app sql rich. Se puoi giustificare un aumento di 6 volte del codice come "semplificato" quindi vai avanti.

Answer 23

Questa è un'ottima domanda! L'ho trovato dopo aver già chiesto a un simliar domanda , ma questo è più specifico. È nato a seguito di una decisione di modifica del design che non ero coinvolto nel prendere.

Fondamentalmente, quello che mi è stato detto è che se hai milioni di righe di dati nelle tabelle del tuo database, allora cerca di mettere la logica di business nelle procedure e nei trigger memorizzati. Questo è ciò che stiamo facendo in questo momento, convertendo un'app Java in stored procedure per la manutenibilità poiché il codice Java era contorto.

Ho trovato questo articolo su: The Business Logic Wars L'autore ha anche creato il milione di righe in un argomento di tabella, che ho trovato interessante. Ha anche aggiunto la logica aziendale in javascript, che è lato client e al di fuori del livello della logica aziendale. Non ci avevo mai pensato prima, anche se ho usato javascript per la convalida per anni, insieme alla convalida lato server.

La mia opinione è che desideri la logica di business nell'applicazione / livello intermedio come regola generale, ma non scartare i casi in cui ha senso inserirla nel database.

Un ultimo punto, c'è un altro gruppo in cui sto attualmente lavorando che sta facendo un enorme lavoro di database per la ricerca e la quantità di dati con cui ha a che fare è immensa. Tuttavia, per loro non hanno alcuna logica aziendale nel database stesso, ma la mantengono nell'applicazione / livello intermedio. Per il loro design, l'applicazione / livello intermedio era il posto giusto, quindi non avrei usato le dimensioni dei tavoli come unica considerazione di progettazione.

Answer 24

La logica aziendale è di solito incarnata dagli oggetti e dai vari costrutti del linguaggio di incapsulamento, eredità e polimorfismo. Ad esempio, se un'applicazione bancaria sta trasferendo denaro, potrebbe esserci un tipo di Denaro che definisce gli elementi di business di ciò che "denaro". è. Questo, al contrario di usare un decimale primitivo per rappresentare il denaro. Per questo motivo, OOP ben progettato è dove la "logica di business" vive & # 8212; non rigorosamente in nessun livello.