Gestione della persistenza dei dati obsoleti

Question

Gestione della persistenza dei dati obsoleti

#1 da (2 voti)
#2 da (0 voti)

1

Attualmente implementato il modello e lavorando sull'interfaccia utente per un'applicazione di pianificazione. Questa è solo un'applicazione interna per il lavoro tra ~ 5 persone che occasionalmente possono far funzionare l'applicazione contemporaneamente.

Verrà eseguito dalla rete e utilizzerà un database SQLite (comprendo i problemi di concorrenza e ritengo che non sarà un problema per il nostro utilizzo). Sembrerà qualcosa del genere:

+------------------------------------------------------------+
|       |1/1/2018 | 1/2/2018 | 1/3/2018 | 1/4/2018 | 1/5/2018|
+------------------------------------------------------------+
|Jack   |Available|Leave     |Leave     |Available |Leave    |
|Jim    |Available|Available |Available |Available |Available|
|John   |Leave    |Leave     |Available |Available |Available|
+------------------------------------------------------------+

Il modello funziona correttamente con un'app console. Attualmente implementando le viste & guarda ora i modelli. Un problema a cui ho pensato per alcuni giorni è cosa fare sui dati obsoleti?

Alla fine implementerò un thread in background che controllerà il database a intervalli impostati dall'utente per un aggiornamento. Questo funzionerebbe bene per le letture, ma mentre parlo di seguito, questo non nega una collezione in memoria nel mio modello?

Tuttavia, non sono sicuro di cosa fare riguardo alle scritture. Quando un utente apporta una modifica alla disponibilità di qualcuno, presumo di voler mantenere tali dati immediatamente in modo che altri utenti possano essere informati. Ma questo non nega le collezioni nel modello (e il modello in realtà), se continuo a persistere direttamente dal viewmodel al database?

Inoltre, cosa devo fare se due utenti stanno apportando modifiche e mi trovo in una condizione di competizione in cui il 2 ° effettua una scrittura utilizzando dati obsoleti perché non ha mai ricevuto l'aggiornamento dal primo utente?

-> User clicks drop down for Jack on 1/1/2018 
-> Drop down displays list of  availability options (e.g. leave, available, unavailable, etc.)
-> user selects different availability option
-> updates viewmodel property with new selected availability
-> updates Jack's schedule in the model 
-> ??? Persist to database immediately and/or do I even need a collection of schedules?

Preferirei farlo da solo e gestire questi problemi in quanto imparerei molto facendolo, quindi preferirei non utilizzare un framework ORM come Entity.

design c# database wpf

posta keelerjr12 01.02.2018 - 01:28

fonte

2 risposte

0

Penso che una manna che ti mancherà senza un framework ORM è la strategia di sfratto della cache. Ad esempio, una cache può essere semplicemente una mappa di identità, che verrà utilizzata per posizionare la raccolta in codice (solo una hashmap globale che elabora i dati in base ad algo predefinito). Ma come dici tu non userai Entità o sonorità, dovrai fare la contabilità: creare una hashmap accessibile a livello globale che abbia ascoltatori sulle tue operazioni di lettura / scrittura (o scrivi solo - decidi in base alla logica di sfratto) e vai per l'accesso regolamentato per modelli e livello di persistenza. È inoltre possibile utilizzare il pattern ActiveRecord in cui modello e persistenza sono legati insieme, il che non è la cosa preferita. Questi sono i miei 4 centesimi.

risposta data 01.02.2018 - 20:42

fonte

Leggi altre domande sui tag design c# database wpf

Best practice dell'API Web che inseriscono dati: nidificati o per entità Salva i dati non così dinamici in un database e recupera le modifiche in futuro

score 2 · Accepted Answer

When a user makes a change to someone's availability, I assume I want to persist that data immediately so other users can be informed. But doesn't this negate the collections in the model (and the model really), if I just persist directly from the viewmodel to the database?

Presumo che tu stia lavorando da un'entità nel tuo Modello. Questa entità contiene i dati aggiornati più recenti dal database, in base all'intervallo di aggiornamento. ViewModel mantiene solo una raccolta ("memorizzata nella cache") di tali entità. La persistenza deve verificarsi alla fine.

What do I do if two users are making changes and I get into a race condition where the 2nd one makes a write using stale data because he never received the update from the first user?

Esegui una lettura immediatamente prima di scrivere, in modo da sapere che hai il record più recente.