Applicazioni Web stateless Sconfiggi DBContext in qualche modo?

1

In Entity Framework, si dice che la classe DBContext implementa il modello dell'unità di lavoro. Interpretando ciò, significa che se si crea un DBContext , si manipolano i suoi dati e poi lo si disfa, allora queste manipolazioni avranno esito positivo o falliranno insieme e verranno ripristinate. Inoltre, c'è il potenziale per un vantaggio in termini di prestazioni, poiché l'infrastruttura sottostante può vedere tutto ciò che stai facendo in una volta sola e fare cose come combinare le operazioni. La sequenza di istanza / manipolazione / eliminazione di solito comprende un blocco che utilizza nella maggior parte del codice C #.

Tutto ciò sembra eminentemente logico, ma quando provo a leggere su DBContext come viene eseguito in un'applicazione ASP.NET MVC, mi imbatto in affermazioni che non riesco proprio ad ottenere, ad esempio:

" DBContext si basa su diverse funzioni gestite e flag che tengono traccia delle modifiche negli elementi che sono stati interrogati dal datastore ... [t] la natura stateless di ASP.NET MVC tuttavia impedisce il funzionamento della funzionalità predefinita di Entity Framework. "

( Sviluppo di applicazioni Web ASP.NET MVC 4, riferimento esame 70-486 di William Penberthy, Microsoft, 2013, pagina 5)

Mi piacerebbe un po 'più specifico su questa presunta rottura nella "funzionalità predefinita di Entity Framework". Devo capire che se costruisco un blocco utilizzando attorno a un DBContext e alcune manipolazioni su di esso, ad esempio, in un metodo controller, allora un passaggio attraverso questo blocco usando non comprende più una singola unità di lavoro? Non posso più aspettarmi che ogni serie di manipolazioni sia impegnata come un'unità intera o ripristinata come intera unità in ASP.NET MVC?

Oppure, in alternativa, la suddivisione in "funzionalità predefinita di Entity Framework" si riferisce esclusivamente ai vantaggi prestazionali ottenibili dall'uso di DBContext ? Immagino che una possibile interpretazione dell'affermazione che sto chiedendo sia solo che più richieste simultanee (ad esempio al mio metodo di controllo di esempio) non avranno le loro manipolazioni di database combinate per un aumento delle prestazioni.

Ad esempio, se 999 persone aggiornano una singola colonna della stessa riga in un database, in rapida successione, tutti questi aggiornamenti finiranno per accadere individualmente ... il che è una cosa che non avrei ritenuto necessario menzionare. Certamente non significa che i utilizzando blocchi costruiti attorno a DBContext funzionano in modo diverso in ASP.NET MVC.

In ogni caso, se capisci la frase che ho citato meglio di me, apprezzerei il tuo aiuto nel comprenderlo.

    
posta user1172763 24.01.2015 - 21:13
fonte

1 risposta

1

Il problema equivale a mantenere lo stato del server in un ambiente applicativo che è stateless per impostazione.

Considera cosa succede quando implementi un carrello. I carrelli della spesa comprendono diversi passaggi: devi scegliere gli articoli che desideri (di solito uno alla volta mentre guardi le pagine dei prodotti), inserire il tuo indirizzo, selezionare il tipo di spedizione, fornire un metodo di pagamento e finalizzare l'ordine.

Ogni pagina inviata al server durante questo processo è essenzialmente una transazione completa. L'architettura REST presuppone che, una volta completato il ciclo richiesta / risposta, non ci sia ancora nulla da fare.

Per tenere traccia dei progressi su un carrello degli acquisti utilizzando un DBContext, si dovrebbe aprire un DBContext, ad esempio, ogni volta che l'utente inserisce il primo articolo nel carrello. Il problema è, dove tieni questo oggetto aperto? I DBContexts sono normalmente chiusi quando la pagina viene inviata. Cosa succede se diversi utenti aprono carrelli della spesa? Ora devo tenere traccia di tutti quei DBContexts. Cosa succede se qualcuno abbandona un carrello della spesa?

Ciò di cui stiamo realmente parlando sono le SESSIONI. Martin Fowler parla ampiamente dello stato SESSION nel suo libro P di EAA, includendo se memorizzare lo stato SESSION sul server o sul client e i vantaggi e gli svantaggi di ciascun approccio.

    
risposta data 24.01.2015 - 22:08
fonte

Leggi altre domande sui tag