Se mettere la logica di business in Stored procedure o no?

21

C'è sempre un dibattito sull'argomento: "Se mettere la logica di business in Stored Procedure o no?". Se decidiamo di non utilizzare lo strumento ORM e di non inserire la logica di business in Stored procedure, dove inseriremo la logica di business?

Nelle mie precedenti applicazioni ho sempre preferito mettere tutta la logica di business solo in Stored procedure. Quindi dal codice .NET chiamo queste stored procedure utilizzando i blocchi applicazione di accesso ai dati. SQLHelper ecc. Ma questo non può essere sempre lo scenario. Quindi ho fatto un po 'di googling ma sono finito in confusione .......

Qualche suggerimento ...?

c# .net sql

— Pravin Patil
fonte

Sono di parte -> Procs memorizzati sempre. Ma poi sono di parte. Dimentica la programmazione Agile, la triste realtà è che nel mondo degli affari i cambiamenti avvengono sempre ad hoc e devono essere fatti "immediatamente". Le procedure memorizzate lo consentono. È un salvavita. Cercare di apportare tali modifiche tramite la base di codice non sarebbe fattibile.

— Darknight,

4

@Darknight, Dipende fortemente dalla tua piattaforma e architettura per fare una dichiarazione del genere. Non vedo perché la distribuzione di una procedura memorizzata in un database richieda molto meno tempo rispetto a dire, eseguire uno script di compilazione e distribuzione per creare un nuovo file WAR, distribuirlo e riavviare il server delle app.

— maple_shaft

7

Stored procedure: la fossa settica dell'informatica.

— Mongus Pong,

1

Stored procedure - solo un altro strumento come un altro.

— sam yi,

15

Adotterò un approccio pragmatico: storicamente il principale "vantaggio" di mantenere la logica di business nei processi archiviati è per motivi di prestazioni (architettura di livello 2.5), mentre separare la logica di business in un livello BLL (livello 3 / N) è generalmente più pulito da un prospettiva di manutenzione e più facile da testare (simulare / eliminare l'accesso ai dati).

Tuttavia, dato che gli ORMS .NET abilitati per LINQ come LINQ2SQL, EF e NHibernate ora creano query SQL con parametri, in cui i piani di query possono essere memorizzati nella cache, sono sottoposti a escape per SQL Injection ecc., Immagino che il passaggio verso l'architettura di livello 3 / N sia più avvincente che mai e la maggior parte degli SPROC (in particolare quelli incentrati sulle query) può essere evitata del tutto. I modelli di repository in .NET comunemente espongono IQueryable / accetta i parametri dell'albero delle espressioni, consentendo un tipo di accesso sicuro, ma flessibile alle tabelle. (Personalmente nelle architetture di tipo SOA, non esporrei IQueryable oltre BLL, vale a dire che i livelli di servizio e presentazione dovrebbero funzionare con una serie ben definita di metodi. Il motivo è che altrimenti non potrai mai testare completamente il tuo sistema e hai vinto '

Tuttavia, in un sistema di dimensioni decenti, ci saranno sempre alcune eccezioni, dove potrebbe essere ancora necessario scrivere un pezzo di codice ad alta intensità di dati come Proc memorizzato per motivi di prestazioni. In questi casi, manterrei lo SPROC ed esporrei lo SPROC attraverso l'ORM, ma espongo comunque la funzione come metodo pass-through sul BLL.

— StuartLC
fonte

1

+1 per scrivere più facilmente unit test a livello di applicazione, tuttavia i framework di test unità DB automatizzati hanno fatto molta strada.

— maple_shaft

14

Essendo uno sviluppatore Java, la mia preferenza era quella di inserire la logica di business nel BLL (controllo della fonte semplice e piacevole, familiarità ecc. Ecc. Ecc.).

Tuttavia, dopo aver lavorato per una grande azienda con molte applicazioni distribuite che utilizzano tecnologie diverse (C #, Java, Pick (non chiedere)) è emerso un vantaggio significativo dell'utilizzo di stored procedure:

Le stored procedure possono essere condivise tra diverse applicazioni .

— Nim Chimpsky
fonte

Ottimo punto

— NoChance,

1

Questo è molto vero e lo usiamo per influire positivamente nel nostro ambiente. Tuttavia, condividere il codice utilizzando il livello dati mi è sempre sembrato un po 'pericoloso. Se hai più consumatori di una determinata logica / dati, preferirei mettere un servizio al suo posto anziché avere più consumatori dello stesso database.

— RationalGeek,

2

Se dividi la tua gestione dei dati in librerie, quelle librerie potrebbero anche essere condivise tra diverse applicazioni teoricamente ...

— Glenatron,

2

Sono parzialmente d'accordo. Tutte queste tecnologie accedono direttamente al database; quindi stai usando le procedure memorizzate per condividere codice comune tra loro. Puoi anche risolvere lo stesso problema avendo un livello intermedio e le soluzioni eterogenee che accedono al tuo livello intermedio invece che al tuo database, e quel livello intermedio condivide tale codice.

— Ekevoo,

1

questa risposta è baloney, 6 anni dopo - solo i dati vanno nel database. Mettendo la logica lì dentro hai un sacco di problemi lungo la linea. Crea microservizio nella tua lingua preferita che accede al db.

— NimChimpsky,

6

Il nostro team ha una regola morbida qui. A volte è meglio risolvere la logica di business in T-SQL, a volte è più facile farlo in c # (livello aziendale).

Quindi abbiamo una soluzione pragmatica: mettiti dove si adatta meglio. So che la teoria a volte è molto severa al riguardo ... ma questa è la teoria :-)

— gsharp
fonte

2

Sicuramente questa è la peggior soluzione di tutte? Come fa uno sviluppatore manutentore a sapere dove è memorizzata la logica? Immagino che a volte si insinua anche nel livello dell'applicazione, o peggio ancora, nell'interfaccia utente?

— Paul T Davies,

2

No. È sempre in Business Layer o T-SQL. Capire dove è memorizzata la logica è probabilmente il problema più piccolo quando si tratta di manutenzione.

— gsharp,

Cosa succede quando qualcuno si unisce al team e tu dici loro questa regola? Come dovrebbero sapere dove qualcosa "si adatta meglio"? Mi sembra quasi una non-regola. Molto soggettivo in base all'individuo.

— RationalGeek,

3

Forza ragazzi, sul serio? Diamo lavoro a persone che hanno un cervello per pensare e venire con qualche esperienza a bordo. Quindi .. oh sì hanno una bocca per chiedere e fare conversazione. Posso dire che il nostro software richiede una manutenzione molto bassa e che le nuove funzionalità possono essere implementate bene da quasi tutti i membri del nostro team. non può essere così sbagliato ciò che facciamo.

— gsharp,

4

Davvero non vedo il senso di abusare di c # per cose che SQL Server può fare molto meglio, e viceversa.

— gsharp,

3

Ci sono vantaggi e svantaggi per entrambi (a mio avviso):

Le procedure memorizzate possono diventare un incubo se non si utilizza una sorta di controllo del codice sorgente SQL (che in molti casi non lo fanno) e su cui ci sono più sviluppatori che ci lavorano. Qualcuno può cambiare una procedura memorizzata e dimenticare di aggiornare il codice che chiama quella procedura e prima di conoscerla hai appena creato e distribuito un sito che genererà eccezioni non gestite (mancata corrispondenza del conteggio dei parametri, ecc.).

D'altra parte, le procedure memorizzate consentono correzioni di errori più rapide in determinate situazioni. Se c'è un bug con una procedura memorizzata, basta risolverlo e il gioco è fatto. Una correzione di bug in un ORM richiede una ricostruzione. A seconda del processo di creazione, questo potrebbe essere lungo / fastidioso.

— AndrewC
fonte

+1 per la necessità di controllo del codice sorgente con proc memorizzati se li utilizzerai pesantemente. Molti DBA con cui ho lavorato sono molto resistenti a questa idea.

— RationalGeek,

2

Mettiamo sempre la nostra logica di business nel livello di logica di business. Se lo metti in Stored Procedure, andrà perso una volta cambiato il tuo RDBMS.

— šljaker
fonte

16

L'ultima cosa che cambia è l'RDBMS ;-)

— gsharp,

Quindi vuol dire che limiti la Stored Procedure a recuperare, aggiornare e inserire i dati ....?

— Pravin Patil,

1

Ogni grande sistema che ho visto, la realtà è che il database è il sistema. I linguaggi di programmazione diventano quasi irrilevanti a questo punto come solo il "front-end" ..

— Darknight

2

@gsharp, non è sempre vero. È possibile che si desideri aggiungere un altro RDBMS come Oracle o sostituire completamente quello esistente. Oppure, in alcuni casi, si desidera sostituire i dati reali con dati fittizi.

— šljaker,

2

@ šljaker ovviamente non è sempre vero. Ma è più probabile che il programma cambi (riprogettazione del software, nuovi linguaggi di programmazione, ecc.) Piuttosto che nel DB.

— gsharp,

2

"Logica aziendale" è un po 'un termine vago. Voglio dire, non ha una sola definizione. Una regola empirica è ridurre al minimo la comunicazione tra i livelli quando è possibile. Pertanto, non è necessario inviare un nome cliente vuoto al server per verificarlo prima di inserire una riga.

Ci sono casi in cui una regola si basa su una lettura del database. Supponi di voler trasferire denaro dal conto 1 al conto 2. Devi leggere entrambi i conti, assicurarti che siano in buono stato e che l'importo nel conto 1 sia sufficiente. In questo caso, il server è un candidato migliore per questa regola perché il client (essendo il BL qui) non deve inviare 3 chiamate al livello del database per questo processo.

Ovviamente, se hai bisogno che la tua soluzione sia indipendente dal database, crea proc memorizzati solo per CRUD (se usato affatto).

— Nessuna possibilità
fonte

1

La logica dovrebbe essere nella BLL sempre perché:

Può essere testato correttamente
Quando SQL 20XX diventa obsoleto e è necessario passare all'ultima versione, non è necessario riscrivere il codice.
Le persone non sono tentate di apportare modifiche al volo (che sembra essere presentato come argomento per SP)
Gli SP, nella mia esperienza, sono il principale punto di errore degli sviluppatori, specialmente dopo alcune generazioni di manutenzione / modifiche.

Credo che dovrebbe esserci una legge che afferma che dopo che un SP è lungo più di X linee, non funziona come previsto.

— Paul T Davies
fonte

Cosa c'è di sbagliato con le modifiche al volo? Se è presente un bug in una procedura memorizzata ed è facilmente risolvibile, risolverlo. È positivo perché significa che non devi fare una nuova uscita per qualcosa di banale. Finché le persone non iniziano a mascherare i bug nel codice modificando le stored procedure, non vedo alcun problema.

— AndrewC,

Per modifiche al volo intendo cose che non sono testate e che non seguono una procedura di rilascio formale. E sì, sp modifiche per mascherare i bug del codice è qualcosa che ho visto un bel po '.

— Paul T Davies,

0

Creiamo un livello di servizi che contiene tutta la nostra logica aziendale implementata nella lingua scelta e utilizziamo il database solo per le query. Questo approccio è una sorta di nostro mandato perché il nostro obiettivo è creare soluzioni COTS per fornire applicazioni con varie implementazioni di database. Hibernate ha dimostrato di essere un salvavita per noi in queste circostanze.

Penso che il più grande vantaggio di questo approccio, oltre alla portabilità del database, sia che puoi trovare tutte le tue risposte in una ricerca.

Inoltre, nonostante alcune delle risposte a un forum, ho un amico che lavora per una compagnia di assicurazioni di fortuna 100 che ha fatto 2 conversioni di database in tre anni perché il database di scelta per la compagnia è cambiato.

— Thom
fonte

0

Nella mia esperienza limitata, preferisco mantenere l'integrità dei dati con le procedure memorizzate e altre funzionalità del database. Ad esempio, se stavo implementando un trasferimento di fondi tra due account, scriverei una procedura memorizzata. Trovo prezioso poter utilizzare più lingue dell'applicazione.

— Kevin Cline
fonte