C'era una volta pratica comune sia per la business logic che per la logica del database da scrivere nella stessa lingua (es. PL / SQL, Transact SQL, ecc.), più recentemente la pratica è quella di separare l'applicazione in livelli / livelli come database, business logic e presentazione, con ogni livello scritto in una lingua diversa. In genere viene utilizzato un ORM per facilitare la comunicazione tra la business logic e il database.
Tuttavia, di tanto in tanto, soprattutto quando l'applicazione è relativamente piccola, continuo a scrivere applicazioni con la logica aziendale spinto verso il basso nel livello del database, solo l'interfaccia utente si trova all'esterno del database. Sono a conoscenza dei vari argomenti a favore e contro questo, tuttavia mi chiedo se esistano buone pratiche contemporanee se si dovesse scrivere un'applicazione di database in questo modo? Esistono parecchi libri sui modelli di dati, ecc., Ma nessuno parla realmente di come strutturare il codice effettivo dell'applicazione in termini di stored procedure, funzioni e così via. Inoltre ci sono una serie di libri sul refactoring del database, o anti-pattern del database, ma di nuovo assumono ampiamente che il database sia usato solo per mantenere i dati.
Ho trovato questo articolo di Blaha, "Progettazione orientata agli oggetti delle stored procedure del database". Esistono altri libri, documenti o database di esempio che illustrano le best practice di progettazione di applicazioni database contemporanee?
In realtà sembra relativamente comune creare ancora applicazioni in questo modo, tuttavia sembra che una delle cose che le persone hanno accettato non sia la migliore pratica, quindi vogliono evitare di parlarne.
Va bene per una procedura di archiviazione aziendale accedere direttamente a una tabella? O tutto l'accesso alla tabella dovrebbe avvenire attraverso i metodi CRUD? Esistono strumenti per la generazione di codice che le persone raccomandano? Grazie.