Sto provando a creare un sistema di dati "distribuito". Il mio primo tentativo è stato creato utilizzando Entity Framework.
Molto liberamente, è costruito attorno ad avere Element oggetti, che a loro volta hanno un gruppo di oggetti Property . Molto simile agli oggetti di classe e alle loro proprietà.
Il motivo è che eventuali modifiche a questi sono sincronizzate tra i moduli distribuiti con un sistema di messaggistica.
Quindi, dire che ho un piccolo servizio che legge alcuni componenti hardware. Ha il "Frigo" Element con Property "Temperatura". Se questo valore di Property cambia, è impostato in questo modo:
TemperatureProperty.Value = 1234;
il sistema di messaggistica lo preleva e, se la proprietà ha il flag IsStream , invia un messaggio e tutti gli altri moduli ricevono l'aggiornamento e attivano un evento OnValueChanged. (Impedisce anche che questo venga scritto nel database).
Quindi l'interfaccia utente, su un altro computer, ha la proprietà della temperatura che riceve un messaggio, si aggiorna e spegne l'evento. UX conosce la modifica e può visualizzare il nuovo valore.
Allo stesso modo, altre modifiche che sono meno comuni, ma richiedono anche una reazione (ad esempio un nuovo Element ), viene inviata una richiesta di modifica "Configurazione". Questo dice al destinatario che l'oggetto che hanno non è aggiornato.
Sto usando un repository centrale. Ogni volta che un oggetto viene richiesto dal repository (o pigro caricato), collega tutti gli eventi rilevanti. I valori in streaming vengono immediatamente inviati al sistema di messaggi, altre modifiche vengono tracciate e propagate con il metodo OnSave:
Ilmiointeroethosstavarendendol'APIilpiùsemplicepossibile.Nondevisaperecheesisteunserviziodimessaggi,osequestaproprietàèinstreaming,inviandomodificheallaconfigurazioneoaltro,senonènecessario.
TiinteressasoloavereunaproprietàTemperature,ehaunnuovovalore,quindilohaiimpostato.Oivalorisonocambiati,quindifaiqualcosa.Tuttoilrestoègestitodal"framework".
Tuttavia, questo si traduce in un DBContext di lunga durata. Il framework entità è sempre 'attivo'. Questo è davvero bello con cui lavorare, poiché il caricamento lento fa funzionare le cose molto bene.
Ma sto leggendo sempre di più che il DBContext dovrebbe essere di breve durata, e certamente non mantenuto "online" per gli intervalli di tempo della durata dell'applicazione.
Con questi piccoli servizi hardware, DBContext sarebbe seduto lì 24 ore su 24 per tenere le cose aggiornate.
Ho anche provato a creare il mio adorabile "basta usarlo come qualsiasi altra cosa" Property in un servizio di test - tranne che ho fatto l'hardware leggendo in un Task (quindi su un thread diverso.) Beh, certo, tutto l'inferno broke perdi perché DBContext non è thread-safe.
Qualcuno ha qualche consiglio su come mantenere le funzionalità, il monitoraggio delle modifiche on-save, ma incorporando la struttura di tipo "Unità di lavoro"?
O dovrei ripensare all'intera architettura e provare ad allontanarmi dal pattern del repository?