Se mettere la logica aziendale in Stored Procedure o Not?

Adottare un approccio pragmatico: storicamente il principale "vantaggio" di mantenere la logica aziendale nei processi memorizzati è per motivi di prestazioni (architettura a livelli 2.5), mentre la separazione della logica aziendale in un livello BLL (livello 3 / N) è generalmente più pulito dal punto di vista della manutenzione e più facile da testare (Mock / Stub out l'accesso ai dati).

Tuttavia, dato che gli ORMS .NET abilitati LINQ come LINQ2SQL, EF e NHibernate ora creano query SQL parametrizzate, dove i piani di query possono essere memorizzati nella cache, sono sfuggiti per SQL Injection ecc, direi che il passaggio verso 3 / N l'architettura di livello è più avvincente che mai e la maggior parte degli SPROC (specialmente quelli basati su query) possono essere evitati del tutto. I modelli di repository in .NET espongono in genere IQueryable / accept Parametri dell'albero di espressione, consentendo un accesso sicuro, ma flessibile alle tabelle. (Personalmente in architetture di tipo SOA, non esporrei IQueryable oltre il BLL, cioè i tuoi livelli di servizio e di presentazione dovrebbero funzionare con un insieme ben definito di metodi.) La ragione è che altrimenti non puoi mai testare completamente il tuo sistema, e non lo farai dormire bene di notte sapendo che alcune query arbitrarie emesse da un client potrebbero colpire il DB senza colpire indici ecc.

Tuttavia, in un sistema di dimensioni decenti, ci saranno sempre alcune eccezioni, in cui un pezzo di codice realmente intensivo di dati potrebbe ancora essere scritto come Proc. memorizzato per motivi di prestazioni. In questi casi manterrei SPROC ed esporremo il SPROC attraverso l'ORM, ma espongo comunque la funzione come metodo pass-through sul tuo BLL.

Essendo uno sviluppatore java, la mia preferenza era mettere la logica aziendale nella BLL (controllo del codice sorgente semplice e intuitivo, familiarità ecc. ecc.).

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

Le stored procedure possono essere condivise tra diverse applicazioni .

La nostra squadra ha una regola morbida qui. A volte è meglio risolvere la Business Logic in T-SQL, a volte è più facile farlo in c # (Business Layer).

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

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

Le stored procedure possono diventare un incubo se non si utilizza una sorta di controllo del codice sorgente SQL (che in molti casi non lo è) e si hanno più sviluppatori che lavorano su di esse. Qualcuno può modificare una procedura memorizzata e dimenticarsi di aggiornare il codice che chiama quella procedura e prima di sapere che hai appena creato e distribuito un sito che genererà eccezioni non gestite (mancata corrispondenza dei parametri ecc.)

D'altra parte, le stored procedure consentono correzioni di bug più veloci in determinate situazioni. Se c'è un bug con una stored procedure, basta ripararlo e il gioco è fatto. Una correzione di bug in un ORM richiede una ricostruzione. A seconda del processo di costruzione, questo potrebbe essere lungo / fastidioso.

Inseriamo sempre la nostra logica aziendale in Business Logic Layer. Se lo metti in Stored Procedure, andrà perso una volta cambiato il tuo RDBMS.

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

Ci sono casi in cui una regola è basata su una lettura di un database. Supponi di voler trasferire denaro dall'account 1 all'account 2. È necessario leggere entrambi gli account, assicurarsi che siano in buono stato e che l'importo nell'account 1 sia sufficiente. In questo caso, il server è un candidato migliore per questa regola perché il client (essendo il BL qui) non ha bisogno di emettere 3 chiamate al livello del database per questo processo.

Ovviamente, se hai bisogno che la tua soluzione sia indipendente dal database, crea procs memorizzati solo per CRUD (se non del tutto utilizzati).

La logica dovrebbe essere sempre nella BLL perché:

• Può essere testato correttamente
• Quando SQL 20XX diventa obsoleto ed è necessario passare alla versione più recente, non è necessario riscrivere il codice.
• Le persone non sono tentate di apportare modifiche in tempo reale (che sembra essere proposto come argomento per SP)
• Gli SP, nella mia esperienza, sono il singolo più grande punto di errore degli sviluppatori, specialmente dopo alcune generazioni di manutenzione / modifiche.

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

Creiamo un livello di servizi che contiene tutta la nostra logica aziendale implementata nella lingua scelta e utilizza solo il database per le query. Questo approccio ci è stato affidato da noi in quanto 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, a parte la portabilità del database, è 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 assicurativa Fortune 100 che ha effettuato 2 conversioni di database in tre anni perché il database di scelta per la società è cambiato.

Nella mia esperienza limitata, preferisco mantenere l'integrità dei dati con stored procedure e altre funzionalità del database. Ad esempio, se dovessi implementare un trasferimento di fondi tra due account, scriverei una stored procedure. Trovo utile poter utilizzare più lingue dell'applicazione.