Come risolvere Optimistic Concurrency aggiornamenti in applicazioni C # .NET n-tier?

Question

Hy tutti.

In C # .NET VS 2008 che sto sviluppando una soluzione di CRM quadro N-tier e quando è fatto voglio condividerlo.

L'architettura si basa su:

Data Access Layer, Entity Framework, Strato Bussines Logic, WCF e, infine, il livello di presentazione (vincere le forme).

Da qualche parte avevo letto, che più di 2 strati di primo livello sono problematici, A causa del Ottimista Concorrenza Aggiornamenti (più transazioni dei clienti con gli stessi dati).

In max. soluzioni di livello 2-tier questo non dovrebbe essere un problema a causa dei controlli (come datagridview) che sono la soluzione di questo problema da soli, quindi mi sto chiedendo se non è meglio lavorare con i livelli 2-tier e così evitare la concorrenza ottimistica problema?

In realtà voglio fare una soluzione strato di N-tier per i progetti di enorme e non 2-livelli. Non so come risolvere i problemi di concorrenza come questo e spero di ottenere aiuto proprio qui.

Di certo ci dovrebbe essere buona alcuni meccanismi per risolvere questo ... forse qualche suggerimento, esempi, ecc.?

ringraziandovi in ??anticipo.

Con i migliori saluti, Jooj

Answer 1

Non è proprio una questione di numero di livelli. La domanda è come fa il tuo accesso ai dati logica accordo con la concorrenza. Si occupano di concorrenza dovrebbe accadere in qualsiasi livello gestisce il vostro accesso ai dati indipendentemente dal numero di livelli che hai. Ma ho capito dove stai venendo da come i controlli .NET ei componenti possono nascondere questa funzionalità e ridurre il numero di livelli necessari.

Ci sono due metodi comuni di risoluzione concorrenza ottimistica.

Il primo utilizza un timestamp sulle righe per determinare se la versione che l'utente stava guardando quando hanno iniziato la loro modifica è stato modificato dal momento in cui commettono la loro modifica. Tenete a mente che questo non è necessariamente un adeguato Timestamp tipo di dati di database. Diversi sistemi utilizzeranno diversi tipi di dati ciascuno con i propri vantaggi e svantaggi. Questo è l'approccio più semplice e funziona bene con la maggior parte dei database ben progettato.

Il secondo approccio comune è, quando impegnandosi modifiche, per identificare la riga in questione non solo da id ma per tutti i valori originali per i campi che l'utente ha modificato. Se i valori originali dei campi e id non corrispondono sull'essere record modificato si sa che almeno uno di questi campi è stato modificato da un altro utente. Questa opzione ha il vantaggio che, anche se due utenti modificare lo stesso record, purché non cambiano gli stessi campi, il commettono opere. Il rovescio della medaglia è che non è possibile lavoro extra per garantire che i dati nel record del database è in uno stato coerente per quanto riguarda le regole di business sono interessati.

Ecco una spiegazione decente di come implementare semplice concorrenza ottimistica in EF.

Answer 2

Usiamo una fusione combinazione manuale (determinazione insiemi di modifiche e collisioni) e le ultime vittorie uomo a seconda delle esigenze di dati. se le modifiche dei dati si scontrano stesso campo cambiato dal valore comune originale quindi unire tipo vengono generate eccezioni ed i clienti di gestire questo.

Answer 3

Un paio di cose mi vengono in mente:

1) Se si utilizza EF sicuramente don'y avete Data Access Layer ?! Hai database di media in sé?

2) Domanda con livelli è sia un phydical e uno logico. Quindi vuoi dire fisica o logica?

3) In applicazione any-tiered c'è la questione con la concorrenza. Anche nel client-server, la gente potrebbe aprire un modulo, andare soemwhere e tornare e quindi salvare, mentre i dati è stato modificato da soemone altro. È possibile utilizzare un timestamp per controllare risparmiando assicurandosi che il vostro ultimo aggiornamento è stato quando hai avuto i dati.

4) Non pensare troppo su meno o più livelli. Basta implementare la funzionalità più semplice possibile e con il minimo numero di strati.