Entity Framework 5 Aktualizowanie rekordu

Badałem różne metody edycji / aktualizacji rekordu w Entity Framework 5 w środowisku ASP.NET MVC3, ale jak dotąd żadne z nich nie zaznacza wszystkich wymaganych pól. Wyjaśnię dlaczego.

Znalazłem trzy metody, o których wspomnę za i przeciw:

Metoda 1 - Załaduj oryginalny rekord, zaktualizuj każdą właściwość

var original = db.Users.Find(updatedUser.UserId);

if (original != null)
{
    original.BusinessEntityId = updatedUser.BusinessEntityId;
    original.Email = updatedUser.Email;
    original.EmployeeId = updatedUser.EmployeeId;
    original.Forename = updatedUser.Forename;
    original.Surname = updatedUser.Surname;
    original.Telephone = updatedUser.Telephone;
    original.Title = updatedUser.Title;
    original.Fax = updatedUser.Fax;
    original.ASPNetUserId = updatedUser.ASPNetUserId;
    db.SaveChanges();
}    

Plusy

• Można określić, które właściwości mają się zmienić
• Widoki nie muszą zawierać wszystkich właściwości

Cons

• 2 x zapytania do bazy danych, aby załadować oryginał, a następnie go zaktualizować

Metoda 2 - Załaduj oryginalny rekord, ustaw zmienione wartości

var original = db.Users.Find(updatedUser.UserId);

if (original != null)
{
    db.Entry(original).CurrentValues.SetValues(updatedUser);
    db.SaveChanges();
}

Plusy

• Tylko zmodyfikowane właściwości są wysyłane do bazy danych

Cons

• Widoki muszą zawierać każdą właściwość
• 2 x zapytania do bazy danych, aby załadować oryginał, a następnie go zaktualizować

Metoda 3 - Dołącz zaktualizowany rekord i ustaw stan na EntityState.Modified

db.Users.Attach(updatedUser);
db.Entry(updatedUser).State = EntityState.Modified;
db.SaveChanges();

Plusy

• 1 x zapytanie do bazy danych do aktualizacji

Cons

• Nie można określić, które właściwości mają się zmienić
• Widoki muszą zawierać każdą właściwość

Pytanie

Moje pytanie do was, chłopaki; Czy istnieje czysty sposób na osiągnięcie tego zestawu celów?

• Można określić, które właściwości mają się zmienić
• Widoki nie muszą zawierać wszystkich właściwości (takich jak hasło!)
• 1 x zapytanie do bazy danych do aktualizacji

Rozumiem, że jest to drobna rzecz, na którą należy zwrócić uwagę, ale może mi brakować prostego rozwiązania tego problemu. Jeśli nie metoda, zwycięży ;-)

Szukasz:

db.Users.Attach(updatedUser);
var entry = db.Entry(updatedUser);
entry.Property(e => e.Email).IsModified = true;
// other changed properties
db.SaveChanges();

Naprawdę podoba mi się zaakceptowana odpowiedź. Wierzę, że istnieje jeszcze inny sposób, aby podejść do tego. Załóżmy, że masz bardzo krótką listę właściwości, których nigdy nie chciałbyś uwzględniać w Widoku, więc przy aktualizacji encji zostaną one pominięte. Powiedzmy, że te dwa pola to Hasło i SSN.

db.Users.Attach(updatedUser);

var entry = db.Entry(updatedUser);
entry.State = EntityState.Modified;

entry.Property(e => e.Password).IsModified = false;
entry.Property(e => e.SSN).IsModified = false;   

db.SaveChanges();   

Ten przykład pozwala zasadniczo pozostawić logikę biznesową w spokoju po dodaniu nowego pola do tabeli Użytkownicy i do Widoku.

foreach(PropertyInfo propertyInfo in original.GetType().GetProperties()) {
    if (propertyInfo.GetValue(updatedUser, null) == null)
        propertyInfo.SetValue(updatedUser, propertyInfo.GetValue(original, null), null);
}
db.Entry(original).CurrentValues.SetValues(updatedUser);
db.SaveChanges();

Dodałem dodatkową metodę aktualizacji do mojej podstawowej klasy repozytorium, która jest podobna do metody aktualizacji generowanej przez Scaffolding. Zamiast ustawiać cały obiekt na „zmodyfikowany”, ustawia zestaw indywidualnych właściwości. (T jest parametrem ogólnym klasy.)

public void Update(T obj, params Expression<Func<T, object>>[] propertiesToUpdate)
{
    Context.Set<T>().Attach(obj);

    foreach (var p in propertiesToUpdate)
    {
        Context.Entry(obj).Property(p).IsModified = true;
    }
}

A potem zadzwonić, na przykład:

public void UpdatePasswordAndEmail(long userId, string password, string email)
{
    var user = new User {UserId = userId, Password = password, Email = email};

    Update(user, u => u.Password, u => u.Email);

    Save();
}

Lubię jedną wycieczkę do bazy danych. Prawdopodobnie lepiej jest to jednak zrobić z widokami modeli, aby uniknąć powtarzania zestawów właściwości. Jeszcze tego nie zrobiłem, ponieważ nie wiem, jak uniknąć przesyłania komunikatów sprawdzania poprawności w moim modelu sprawdzania poprawności do mojego projektu domeny.

public interface IRepository
{
    void Update<T>(T obj, params Expression<Func<T, object>>[] propertiesToUpdate) where T : class;
}

public class Repository : DbContext, IRepository
{
    public void Update<T>(T obj, params Expression<Func<T, object>>[] propertiesToUpdate) where T : class
    {
        Set<T>().Attach(obj);
        propertiesToUpdate.ToList().ForEach(p => Entry(obj).Property(p).IsModified = true);
        SaveChanges();
    }
}

Wystarczy dodać do listy opcji. Możesz także pobrać obiekt z bazy danych i użyć narzędzia do automatycznego mapowania, takiego jak Auto Mapper, aby zaktualizować części rekordu, które chcesz zmienić.

W zależności od przypadku zastosowania obowiązują wszystkie powyższe rozwiązania. Tak zazwyczaj jednak to robię:

W przypadku kodu po stronie serwera (np. Proces wsadowy) zwykle ładuję encje i pracuję z dynamicznymi serwerami proxy. Zwykle w procesach wsadowych dane należy ładować w każdym momencie w momencie uruchomienia usługi. Próbuję wsadowo ładować dane zamiast korzystać z metody find, aby zaoszczędzić trochę czasu. W zależności od procesu używam optymistycznej lub pesymistycznej kontroli współbieżności (zawsze używam optymistycznej, z wyjątkiem scenariuszy wykonywania równoległego, w których muszę zablokować niektóre rekordy za pomocą zwykłych instrukcji SQL, jednak jest to rzadkie). W zależności od kodu i scenariusza wpływ można ograniczyć do niemal zera.

W przypadku scenariuszy po stronie klienta masz kilka opcji

1. Użyj modeli widoku. Modele powinny mieć właściwość UpdateStatus (niezmodyfikowane-wstawione-zaktualizowane-usunięte). Klient jest odpowiedzialny za ustawienie poprawnej wartości w tej kolumnie w zależności od działań użytkownika (wstaw-aktualizuj-usuń). Serwer może albo zapytać db o oryginalne wartości, albo klient powinien wysłać oryginalne wartości do serwera wraz ze zmienionymi wierszami. Serwer powinien dołączyć oryginalne wartości i użyć kolumny UpdateStatus dla każdego wiersza, aby zdecydować, jak obsłużyć nowe wartości. W tym scenariuszu zawsze używam optymistycznej współbieżności. Spowoduje to jedynie wykonanie instrukcji insert-update-delete, a nie wyborów, ale może potrzebować sprytnego kodu, aby przejść wykres i zaktualizować encje (w zależności od scenariusza - aplikacji). Program mapujący może pomóc, ale nie obsługuje logiki CRUD

2. Użyj biblioteki takiej jak breeze.js, która ukrywa większość tej złożoności (jak opisano w 1) i spróbuj dopasować ją do swojego przypadku użycia.

Mam nadzieję, że to pomoże