Update-Methode für generic Entity framework-repository

Habe ich ein repository wie:

public class Repository<T> : IRepository<T> where T : class 
{
    private readonly IRepositoryContext _repositoryContext;

    public Repository(IRepositoryContext repositoryContext)
    {
        _repositoryContext = repositoryContext;
        _objectSet = repositoryContext.GetObjectSet<T>();
    }

    public virtual void Update(T entity)
    {
        ObjectSet.AddObject(entity);
        _repositoryContext.ObjectContext.ObjectStateManager.ChangeObjectState(entity, EntityState.Modified);
        _repositoryContext.SaveChanges();
    }
  }

Nun, tatsächlich funktioniert für alle skalaren Eigenschaften der Entität, aber auch alle anderen Personen, die im Zusammenhang mit Eigenschaften von entity -typeOf(T), kümmern sich nicht, die entity-Zustand geändert wird, und EF-einfach neue Daten Hinzugefügt werden.

So, wenn Sie zum Beispiel Repository<Student>.Update(), und Sie änderten nur die Namen, es wird das richtige Studenten-und seinen Namen ändern, aber es wird auch ändern Sie den Campus, obwohl Sie bereits eine Campus zugeordnet ist, der student ist, wird er erstellt wieder mit einer anderen CampusId.

Zeig mir bitte den richtigen Weg, um updates in dieser situation.

Willkommen im club der EF-User-unter-der-Schmerzen-nach-update-Beziehungen-und-Verwandte-Personen. Sie werden wahrscheinlich nicht finden, eine generic Lösung für ein Update Methode. Es ist einer der Hauptgründe, warum generischen repositories allein in EF sind so nutzlos (es sei denn als innere Helfer im inneren der aggregate-repositories vielleicht).
Es ist keine richtigen Weg. Einfach generische Ansatz funktioniert nicht in diesem Fall.
gut, könnten Sie mir zeigen, dann nicht-generischer Ansatz für die situation, wo ich nicht wirklich operieren mit Entitäten direkt. Stattdessen habe ich in der Zuordnung zu ViewModel-Klassen durch AutoMapper
Hier sind die code-Beispiele, wie Sie das update eine freistehende Einheit, die hat ein einziges Kind Sammlung: stackoverflow.com/q/5538974/270591. Grundsätzlich: Laden Sie die original-graph-Objekt aus DB, vergleichen Sie mit Ihrem geändert, freistehendes Objekt, Diagramm, gelten alle änderungen, die Sie erkennen, um das original und speichern. Es ist für DbContext, aber die Idee ist die gleiche für ObjectContext. Es wird viel komplizierter, bei einem komplexeren Objekt-Graphen (mit mehreren Sammlungen und grand Kind Sammlungen und so weiter). Gibt es vielleicht andere Wege, aber wahrscheinlich nicht viel einfachere Wege.

InformationsquelleAutor iLemming | 2011-07-27

  1. 4

    Was ich Tat, als ich Folgen wollte generischen Ansatz wurde übersetzt, um Ihren code so etwas wie:

    public class Repository<T> : IRepository<T> where T : class 
{
    ...

    public virtual void Update(T entity)
    {
        if (context.ObjectStateManager.GetObjectStateEntry(entity).State == EntityState.Detached)
        {
            throw new InvalidOperationException(...);
        }

        _repositoryContext.SaveChanges();
    }
}

    Alle mein code dann so funktioniert:

    var attachedEntity = repository.Find(someId);
//Merge all changes into attached entity here
repository.Update(attachedEntity);

    => Tun dies in generischer Weise bewegt sich viel Logik in die Obere Ebene. Es gibt keine bessere Art und Weise, wie Sie speichern große, freistehende Objekt-Graphen (vor allem, wenn viele-zu-viele-Beziehungen beteiligt sind, und löschen von Beziehungen beteiligt ist).

    Das problem bei dieser Lösung ist, dass Sie nur berücksichtigt zu Aktualisieren, aber das gleiche problem tritt bei Einfügen auf ein neues Objekt. Wenn Sie ein Objekt einfügen, das ist mit anderen detached entities, die bereits in der Datenbank vorhanden sind (die wiederum mit anderen Entitäten/sub-Entitäten), die alle diese Objekte werden neu erstellt. Was für ein Alptraum. Dies scheint wie ein unnötiges Verhalten, vor allem, da diese freistehende Objekte alle haben hydratisiert ID-Eigenschaften, so wäre es wirklich einfach, zu erkennen, dass Sie bereits geladen wurden, in einem vorherigen Aufruf.

    InformationsquelleAutor Ladislav Mrnka

Schreibe einen Kommentar