Quando l'app desktop deve essere salvata nel database usando UoW?

Question

Quando l'app desktop deve essere salvata nel database usando UoW?

#1 da (2 voti)

2

Quindi una cosa a cui non ho davvero pensato quando ho progettato questa applicazione di finanza personale è stata WHEN (non come) per mantenere i dati. Sto usando DDD, un'architettura a 4 livelli e EF.

Mi ha colpito quando ho aggiunto una nuova transazione, un account, ecc. che è stato immediatamente salvato nel DB. Tuttavia, questo non è il modo in cui la maggior parte delle applicazioni desktop funziona. Persino TurboTax crea un file che desidera salvare con Ctrl + S.

Quindi la mia domanda è, con la persistenza del DB, ha senso solo per me chiamare uow.SaveChanges() in risposta al comando di salvataggio di un utente (tramite Ctrl + S)? O dovrei farlo con ogni aggiunta / cancellazione / ecc.?

Ora che ci penso, penso che GnuCash usi solo un file per salvare tutti i dati (che a me sembra strano).

domain-driven-design database desktop-application

posta keelerjr12 19.04.2018 - 00:19

fonte

1 risposta

Leggi altre domande sui tag domain-driven-design database desktop-application

Un server di hosting di file è un attore secondario in un caso "Riproduzione di un video"? Come separare la logica di costruzione e runtime in iOS?

score 2 · Accepted Answer

So my question is, with DB persistence, does it only make sense for me to call uow.SaveChanges() in response to a user's save command (via Ctrl + S)? Or should I do it with every addition/deletion/etc.?

Dipende.

Trattare ogni azione dell'utente come un comando da valutare e archiviare nel modello di dominio è una scelta ragionevole. Ogni comando è rappresentato da un messaggio passato dal componente dell'applicazione al componente del modello di dominio. Immagino la giuntura che mi servirebbe se usassi l'applicazione come interfaccia per una web api - ogni comando sarebbe un POST / PUT / PATCH / DELETE che il server gestirà.

Un altro potrebbe essere separare i concetti di "bozza" e "pubblicazione" nel modello di dominio. Ogni sessione di modifica ottiene la propria bozza (con il proprio ciclo di vita e regole di pulizia) e il pulsante Salva attiva un comando che pubblica la bozza corrente.

È possibile trattare le bozze come qualcosa che appartiene a un transitorio, nel modello di memoria, e i report pubblicati come residenti nel database - non c'è una regola che dice che tutti i tuoi aggregati devono far parte dello stesso archivio dati ( anche se ci sono complessità quando si tenta di coordinare le modifiche tra negozi separati).

Un'altra possibilità interessante è considerare le modifiche come apportate in un client occasionalmente connesso , con il pulsante di salvataggio che funge da azione "sincronizza le modifiche in memoria con l'archivio remoto".