Wprowadzenie

Pracując z Entity Framework możemy doceniać jego moc oraz zapomnieć o tym, jaką potężną magią on operuje. Np. skąd ten diabeł wie, co się zmieniło, a kiedy muszę mu o tym przypomnieć.

Mam prostą regułę w głowie, jeśli wyciągam dane z kontekstu i zaraz od razu wrzucam je tam z powrotem, nie ustawiam do tego flag, nie wtrącam się, nie robię hokus-pokus i zakładam, że wszystko będzie dobrze.

Jeśli wyciągam dane na dłużej, wtedy podpowiadam EF, żeby nie śledził zmian, bo to trochę zajmie, zanim te dane wrócą do bazy danych i szkoda zachodu.

Dane można zapisać / zaktualizować na kilka sposobów:

Na raz:

• Pobierz
• Zmodyfikuj
• Zapisz

Na dwa

• Utwórz
• Przypnij
• Zapisz

Na trzy:

• Nie zaglądam, jeśli działa u Ciebie to dawaj dawaj na produkcje

Wygląda że proste? To sprawdzam, co i jak zadziała

W obu przypadkach mam taki oto kod:

	public class BlogDbContext : DbContext
	{
	public BlogDbContext(DbContextOptions<BlogDbContext> options) : base(options){}
	public DbSet<Post> Posts { get; set; }
	}
	public class Post
	{
	public Guid Id { get; set; }
	public string Title { get; set; }
	public DateTime ReleaseDate { get; set; }
	public DateTime? UpdateDate { get; set; }
	}

view raw BlogDbContext.cs hosted with by GitHub

Nie oszukujmy się, bunkrów nie ma, kontekst oraz jakiś POCO na potrzeby przykładów.

Uno

	var m = _blogDbContext.Posts.Single(x => x.Id == id);
	m.UpdateDate = DateTime.Now;
	m.Title = title;
	_blogDbContext.SaveChanges();

view raw ef-savechanges.cs hosted with by GitHub

Ten przykład działa, pobieram, modyfikuje, zapisuje. EF robi magię i potrafi sam wykryć zmianę w encji – nie wymaga wywołania `update` aby znaleźć i nanieść zmiany na obiekcie. PFM! Wymagany jest natomiast strzał do bazy aby pobrać początkowy obiekt do modyfikacji.
Na plus – nie tracę informacji, który nie modyfikuje. Wrócę do tego niżej.

Duo(s)

Teraz się zacznie, co się stanie, gdy wyciągnę dane bez śledzenia i zapiszę zamiany:

	var m = _blogDbContext.Posts.AsNoTracking().Single(x => x.Id == id);
	m.UpdateDate = DateTime.Now;
	m.Title = title;
	_blogDbContext.SaveChanges();

view raw save-no-tracking.cs hosted with by GitHub

Pudło! Nic, EF cichutko “zapisał” zmienione encje, ale mój odcięty obiekt nie był na tej liście, w związku z tym – nic się nie wydarzyło. Może tylko odrobina smutku. Ale sam tego chciałem, przecież mówiłem – bez śledzenia!

Spróbuje inaczej, stworze nowy obiekt, przypnę go do kontekstu i wtedy zapisze:

	var m = new Post
	{
	Id = id,
	Title = title,
	UpdateDate = DateTime.Now
	};
	_blogDbContext.Posts.Attach(m);
	_blogDbContext.SaveChanges();

view raw edit-attach-save.cs hosted with by GitHub

Hus! (Dzięki panie Łukaszu) – nie działa! Ale czemu? Przecież obiekt jest w kontekście!

	/// <summary>
	/// This is an internal API that supports the Entity Framework Core infrastructure and not subject to
	/// the same compatibility standards as public APIs. It may be changed or removed without notice in
	/// any release. You should only use it directly in your code with extreme caution and knowing that
	/// doing so can result in application failures when updating to a new Entity Framework Core release.
	/// </summary>
	public override EntityEntry<TEntity> Attach(TEntity entity)
	{
	var entry = EntryWithoutDetectChanges(entity);
	SetEntityState(entry.GetInfrastructure(), EntityState.Unchanged);
	return entry;
	}

view raw ef-core-8-Attach.cs hosted with by GitHub

Ach, obiekt został dodany, ale jest oznaczony jako unchanged! Ok-sprawdzam:

	var m = new Post
	{
	Id = id,
	Title = title,
	UpdateDate = DateTime.Now
	};
	_blogDbContext.Posts.Attach(m);
	m.Id = id;
	_blogDbContext.SaveChanges();
	return RedirectToAction("Index");

view raw blog-attach-2.cs hosted with by GitHub

Czyli co, nawet jeśli mam nowy obiekt i przypiąłem go do kontekstu nadal nie jest śledzony? Nie koniecznie, obiekt został przypięty i jest śledzony, ale zmiany nie nastąpiły po włączeniu śledzenia. Natomiast taki kod:

	var m = new Post
	{
	Id = id,
	};
	_blogDbContext.Posts.Attach(m);
	m.Title = title;
	m.UpdateDate = DateTime.Now;
	_blogDbContext.SaveChanges();

view raw blog-attach-modify-save.cs hosted with by GitHub

Robi już robotę, zwróć uwagę, że zmiany następują po przypięci i włączeniu śledzenia zmian

Zamiast takiego cyrkolenia się, można iść na skróty i wywołać po prostu Update:

	var m = new Post
	{
	Id = id,
	Title = title,
	UpdateDate = DateTime.Now
	};
	_blogDbContext.Update(m);
	_blogDbContext.SaveChanges();

view raw blog-update-save.cs hosted with by GitHub

Który ustawia status obiektu na modified i zapisuje zmiany.

Turbo mega uwaga:
Oba przypadku zerują wartość dla ReleaseDate który dostanie domyślną 01.01.0001 00:00:00 wartość-trzeba tego pilnować. W przypadku gdy wcześniej ładujemy obiekt z DB a potem go modyfikujemy, ReleaseDate jest ustawiony i nie nadpisany zerową wartością.
Pewnie można by poszukać i podpowiedzieć, które właściwości zostały zmienione, ale to wymagałoby znajomości voodoo.

Dodam tylko dla optymalizacji, że gdy wyciągamy obiekt z EF, który nie będzie zmieniany, np. tylko żeby wyciągnąć i wyświetlić, warto użyć opcji `
AsNoTracking, aby podpowiedzieć EF zaprzestania śledzenia obiektów, bo zniknąć one z naszego kontekstu.

	var movies = _blogDbContext.Posts.AsNoTracking().ToList();
	return View(movies);

view raw as-no-tracking.cs hosted with by GitHub

Jeśli zaistnieje potrzeba ponownego podpięcia, można zrobić attach lub update – ale to już wiesz.

Szczegóły tutej:
https://learn.microsoft.com/en-us/ef/core/change-tracking/

ps.
Tak naprawdę to nie korzystam z EF.

ps2.
Źródło całego pliku cs dostępne tutaj:
https://gist.github.com/jstadnicki/9a97619c26e4ba9571fa2aec40be25d3