Qual è il modo corretto di gestire non-tracking entità auto di tracciamento?

Question

entità Auto inseguimento. Impressionante.

Tranne quando si fa qualcosa come

return Db.Users;

nessuna delle entità auto-tracking stanno rintracciando (fino, forse, sono deserializzate).

Bene. Quindi dobbiamo riconoscere che c'è una possibilità che un'entità tornando a noi non hanno attivato il monitoraggio.

Ora che cosa ???

Le cose che ho provato

Per il dato corpo del metodo:

using (var db = new Database())
{
    if (update.ChangeTracker.ChangeTrackingEnabled)
        db.Configurations.ApplyChanges(update);
    else
        FigureItOut(update, db);

    db.SaveChanges();
    update.AcceptChanges();
}

Le seguenti implementazioni di FigureItOut tutti falliscono:

db.Configurations.Attach(update);
db.DetectChanges();

Non

db.Configurations.Attach(update);
db.Configurations.ApplyCurrentValues(update);

Non

db.Configurations.Attach(update);
db.Configurations.ApplyOriginalValues(update);

Non

db.Configurations.Attach(update);
db.Configurations.ApplyChanges(update

Né di qualsiasi altra cosa che posso capire a buttare a questo, diversi da

1. Come l'entità originale dal database
2. Confrontando ogni proprietà a mano
3. Aggiornamento proprietà come necessario

Che cosa, esattamente, dovrei fare con entità auto-monitoraggio non stanno monitorando la loro ??

---

Piccolo aggiornamento:

ciecamente segna l'entità come opere modificati, tuttavia questo sembra un po 'puzzolente. E 'la cosa migliore che possiamo fare in questo caso?

Answer 1

lo scenario 1

Ecco alcune procedure consigliate da seguire. Quando si utilizza STE nello scenario WCF, si dovrebbe fare affidamento sul tracker cambiamento che STE implementa così sul lato server di effettuare le seguenti.

db.Users.ApplyChanges(user);
db.SaveChanges();

scenario 2 Tuttavia, se siete sul server, la prassi consigliata è quella di creare un metodo della classe parziale per ObjectContext chiamato EnableChangeTracking. Il metodo potrebbe interrogare per i soggetti che si trovano in stato immutato che implementa IObjectWithChangeTracker e accende il rilevamento delle modifiche in modo da qualcosa di simile

user = db.users.first(u => u.userid == 1);
db.EnableChangeTracking();

ora cercare di salvare l'impresa utente da un contesto diverso da cui è stato originariamente recuperato dal

db2.users.ApplyChanges(user);
db2.SaveChanges();

scenario 3 se sul lato server si è connessi allo stesso contesto oggetto da cui è stato recuperato l'entità utente, quindi si utilizza STE come semplice oggetto poco come qui di seguito

user = db.users.first(u => u.userid == 1);
user.LastName = "XYZ";
db.DetectChanges(); //no need for it cuz Savechanges implicitly calls this.
db.SaveChanges();

scenario 4 se l'entità utente viene recuperato da un contesto diverso, allora il contesto u lo userà per salvare ecco allora un'altra opzione dove u segnano l'entità, come modificato e non importa cosa ma ho modificato.

user = db.users.first(u => u.userid == 1);
var db2 = new ObjectContext();
user.LastName = "XYZ";
db2.Users.Attach(user);
// i prefer this option..
db2.ObjectStateManager.ChangeObjectState(user,EntityState.Modified); 
db2.SaveChanges(); // updates all columns

scenario 5 se l'entità utente viene recuperato da un contesto diverso, allora il contesto u lo userà per salvare ecco allora un'altra opzione dove u recuperare l'entità originale.

user = db.users.first(u => u.userid == 1);
user.lastName ="XYZ";
var db2 = new ObjectContext();
db2.Users.First(u => u.userid == user.userid);
db2.users.ApplyCurrentValues(user);
db2.SaveChanges();

Ecco un post sul blog che descrive alcuni scenari. http: / /weblogs.asp.net/zeeshanhirani/archive/2010/03/30/modifying-self-tracking-entity-on-the-server.aspx

I ampiamente coprire questi concetti nel mio Entity Framework 4.0 il libro di ricette con un sacco di scenari ..