Recentemente sono incappato in questo parere dal 2016 affermando che c'è ancora un caso per la logica di dominio nel database.
Ho pensato che fosse completamente obsoleto. Mi sto solo chiedendo se il ragazzo stia ancora vivendo negli anni '90 o questo può essere vero. Metti da parte i sistemi legacy.
Che dire della logica di dominio nel database a causa dei requisiti di sicurezza. È davvero una cosa da fare?
I programmatori al giorno d'oggi sembrano pensare molto dogmaticamente, specialmente quando leggono i pensieri che altre persone scrivono nei loro blog.
Prendi il blog di Bob Martin's Clean Coding, ad esempio. Come osservazione generale, trovo gli scritti di Bob Martin abbastanza chiari e chiari, quindi mi sconcerta che le persone siano costantemente confuse dalle cose che scrive, come i principi SOLID. Restano appesi a quello che dovrebbe essere una "Single Responsibility", o perché una qualche classe viola i principi di Liskov, quando ciò che probabilmente dovrebbero fare è semplicemente cercare di scrivere un codice migliore, e ottenere prima esperienza, in modo che quello che leggono in i blog hanno un contesto.
Fondamentalmente quello che stai dicendo è che il database dovrebbe contenere tabelle e dati, e questo è tutto ciò che dovrebbe contenere. Ma i database sono particolarmente adatti per fare certe cose che ... beh, i database sono bravi.
L'articolo cita queste cose:
come cose idonee da inserire nel database. Sono d'accordo con lui.
Motivi per cui non si inserisce la logica di business (in generale) in un database:
Ma queste cose generalmente si applicano solo a quelle tecniche, strumenti e formazione per i quali il database non è univoco.
Quindi, come con qualsiasi altra tecnica nello sviluppo del software, dipende. Valutate le vostre alternative e prendete la decisione in base a ciò che ritenete sia la migliore linea di condotta possibile per la vostra applicazione specifica.
L'età di cavallo e buggy è finita, ma puoi ancora comprare fruste buggy.
Perché? Quando le auto sono più veloci, meno costose da mantenere, e trascurarle non produrranno visite dalla società umana, perché il cavallo e il carrello sono ancora in circolazione?
Perché a volte hai motivi diversi per fare qualcosa oltre alle ragioni popolari.
Quello che dovresti imparare è perché la logica di dominio in un database causa problemi e ciò che chiunque potrebbe ottenere da esso. Allora prendi la tua idea.
La mia opinione personale:
La logica del dominio riguarda il comportamento. I database riguardano la persistenza, le relazioni e, beh, i dati. Quando lo vedi in questo modo le regole aziendali non dovrebbero essere nel database.
D'altra parte chi, ha detto che il database non può avere un comportamento? Ho creato database dell'ufficio usando Filemaker. La gente lo chiama un database ma è anche un intero ambiente di sviluppo di applicazioni. Tutto perfettamente integrato in uno e chiamato database.
Wizdom si trova di solito tra le visualizzazioni estreme. Non ho alcun dubbio che potrebbe essere fatto funzionare. Quando cerchi di trovare il centro è allettante seguire la mandria. Metterò in guardia contro questo qui.
Un sistema che mantiene la logica di dominio nel database può funzionare bene. Un sistema che mantiene la logica di dominio fuori dal database può funzionare bene. Un sistema che mescola la logica di dominio in entrambi i posti mi farà impazzire. Non saprò dove mettere un nuovo comportamento. Non sarò sicuro su dove trovare il vecchio comportamento.
Se ancora non riesci a decidere di lanciare una moneta e prendere la sua decisione come vangelo per un particolare progetto. Per quanto posso dire che la moneta sa cosa è meglio come chiunque altro.
Avevo un caso in cui risolverlo nel livello aziendale sarebbe stato un vero killer delle prestazioni.
La nostra applicazione Il concetto di sicurezza OO comprende ruoli e gruppi. Ed entrambi sono strutture ricorsive. Abbiamo scritto una procedura memorizzata che risolve il permesso per un utente su un oggetto dominio.
Ci sono davvero meno necessità di ricorrere alla logica del database. Ma in questo caso ho deciso di andare in quel modo. Ma cosa devi sempre considerare: ti arrendi dall'astrazione. Non appena hai una logica di business nel database, hai una dura giornata per cambiare il tuo livello di persistenza. Quindi stai molto attento.
Leggi altre domande sui tag database