It's great for DDD too! With the current version of EF Core we can already lock down our entities quite nicely, without having to worry about the reconstitution from DB, because usually it just works without even thinking about it. So an anemic domain model is absolutely not necessary anymore.
I cannot even express how long I've been beating my head against the wall trying to figure out why my property changed events weren't firing... I'm stuck trying to work with a SQL Server database that CANNOT HAVE PRIMARY KEYS ADDED in the tables, of all the crazy things, and so I'm trying to build this viewmodel that has references from 2 tables that don't have change tracking automagically working. From what I can tell the best way to do this is to do a sort of... jedi mind trick... hand wavey ... "Don't worry about it EF Core, it TOTALLY HAS a primary key anyway" thing.. and then. call CRUD stuff out more explicitly when it changes on the properties. Well this video explained why my private backing fields were changing in my POCO's and not saving in the database.. seriously though, how crazy is it that this is even allowed to happen? I get there's some sort of use case for it, but private backing fields are supposed to be private... and ... like.. not magically changing and not telling anyone... right? *Sigh* Anyway, a thousand blessings upon you and your families and your dog or ferrets or whatever.. you're seriously my heroes. lol. God bless.
![Getting Started with Entity Framework Core [1 of 5] | Entity Framework Core for Beginners](http://i.ytimg.com/vi/SryQxUeChMc/mqdefault.jpg)
It's great for DDD too! With the current version of EF Core we can already lock down our entities quite nicely, without having to worry about the reconstitution from DB, because usually it just works without even thinking about it. So an anemic domain model is absolutely not necessary anymore.
Hi great work guys. Please did you cover using spatial data with EF core somewhere in the series?
I cannot even express how long I've been beating my head against the wall trying to figure out why my property changed events weren't firing...
I'm stuck trying to work with a SQL Server database that CANNOT HAVE PRIMARY KEYS ADDED in the tables, of all the crazy things, and so I'm trying to build this viewmodel that has references from 2 tables that don't have change tracking automagically working. From what I can tell the best way to do this is to do a sort of... jedi mind trick... hand wavey ... "Don't worry about it EF Core, it TOTALLY HAS a primary key anyway" thing.. and then. call CRUD stuff out more explicitly when it changes on the properties. Well this video explained why my private backing fields were changing in my POCO's and not saving in the database..
seriously though, how crazy is it that this is even allowed to happen?
I get there's some sort of use case for it, but private backing fields are supposed to be private... and ... like.. not magically changing and not telling anyone... right? *Sigh*
Anyway, a thousand blessings upon you and your families and your dog or ferrets or whatever.. you're seriously my heroes. lol.
God bless.
Took me watching it 2.5 times to finally get that IsDirty=true; because of the SaveChanges in the first using-block o_0
I watched several times...I cant get the point.!!!!!