Ho lavorato a un'applicazione di gestione delle vendite multilivello sviluppata con WPF e parzialmente refactored con EF6 (lunga storia). L'applicazione ha alcune attività molto complesse che richiedono più chiamate al database con evidenti problemi di prestazioni. Ad esempio, per emettere un ordine cliente, l'applicazione esegue un'attività che richiede la lettura, l'inserimento e l'aggiornamento di almeno una dozzina di tabelle DB o più. Ci sono evidenti problemi architettonici. Un refactoring è fuori questione perché richiederebbe riscrivere l'intera applicazione. Ma non potevo smettere di pensare a come avrei affrontato un'applicazione che richiedeva la scrittura di dati su così tanti tavoli se avessi avuto la possibilità di scriverla da zero.
Quindi, se dovessi sviluppare un'applicazione con tali requisiti e dovessi mantenere l'EF6 come tecnologia sottostante, la mia domanda è: come progetteresti le attività che richiedevano più chiamate DB? Ho pensato ad alcune opzioni:
-
scrivendo i dati su 1 o 2 tabelle principali, scrivendo il resto dei dati correlati su una tabella di supporto e abilitando i trigger sul DB che distribuirebbero i dati dalla tabella di supporto alle tabelle di destinazione.
-
chiamando una singola stored procedure che si occuperà di scrivere tutti i dati nelle tabelle di destinazione (ma non sono un fan della scrittura di business logic nel DB)
-
utilizzando le chiamate asincrone dove possibile, ma potrebbe risultare complicato per mantenere sincronizzati i contenuti.
-
suddividere l'attività in modo che i dati correlati vengano scritti in un batch automatizzato in un secondo momento. Questa opzione mi sembra la più soggetta a errori.
Qualche pensiero?