Migliori pratiche di progettazione delle applicazioni del database [duplicato]

11

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.

    
posta Antonio2011a 26.08.2011 - 04:46
fonte

1 risposta

7

Direi che potresti facilmente giustificare l'inserimento della logica nel livello del database. Si tratta davvero di incapsulamento. Se stai chiamando stored procedure per accedere ai tuoi dati allora stai incapsulando quella logica aziendale come se avessi uno strato ORM.

Penso che a volte le persone si pieghino sulla scalabilità e sulla portabilità quando davvero non ne hanno bisogno. Se le tue applicazioni non hanno l'obbligo di funzionare su sistemi di database diversi (come una libreria open source o qualcosa che vendi ai client), non vedo un problema con questo.

Mentre ci sono molti strumenti per ORM e l'ordinamento, se sei a tuo agio con le stored procedure e il tuo cliente (che sia la società per cui lavori o un cliente pagante) è a suo agio con il supporto di questo, quindi è un buona idea. È quindi possibile posizionare un livello Web dell'interfaccia utente molto leggero e, in tal caso, è probabile che anche un servizio web o un'altra API siano abbastanza facili da gestire, dal momento che è stata incapsulata la logica aziendale.

    
risposta data 31.08.2011 - 16:40
fonte