Entity Framework Core 1.1 was released last November. With it, besides some bug fxes and semi-transparent improvements, came along a few goodies. If you read my previous post on features missing in Entity Framework Core 1.0, you’ll be please to know that a few have been addressed.
The Find method, for returning an entity from its primary key, is back (I had provided a workaround here):
New is GetDatabaseValues, which goes to the database and fetches the current values for the current entity and primary key:
It is now again possible to reload an entity, causing it to be re-hydrated with the current values from the database, through the Reload method (also available as a workaround here):
And it is also possible to force load a not-loaded collection ():
As well as entity references (one-to-one, many-to-one):
Connection resiliency made it way to version 1.1 as well:
The EnableRetryOnFailure method is just a wrapper around ExecutionStrategy passing it SqlServerRetryingExecutionStrategy:
This one allows you to provide your own strategy for retries, by implementing IExecutionStrategy.
Now, this is something that could have been really cool, but, as it is now, I find it somewhat crippled… you can now tell Entity Framework Core how should it find out if an entity has changed – the common change tracker functionality. But, the only supported techniques are the built-in (default, based on snapshots) or the use of INotifyPropertyChanged/INotifyCollectionChanged. This is not really that extensible, as you only have these two options. Here is how you configure it:
If you want to use this approach, your entity must implement INotifyPropertyChanged and all of its collections must implement INotifyCollectionChanged. If any of the properties or collections in it changes, you must raise the PropertyChanged or CollectionChanged events, otherwise EF will not know that it is modified.
This can be set as the default for all entities, by the way:
A most welcome addition, that was never previously available, is mapping to fields! This better supports a pure Domain Driven Design approach. It needs to be configured using code mapping:
Another handy improvement is the ability to map collections declared as IEnumerable<T>, whereas in the past this was only possible for ICollection<T> (and derived classes, of course). The configuration is the same:
Of course, the concrete collection class must itself implement ICollection<T>, otherwise Entity Framework would have no way to populate it:
In case you are using Hekaton, you can now tell Entity Framework that your entity is persisted as a memory-optimized table:
Last, but not least, EF Core 1.1 makes it much easier to replace one of the services that EF uses internally:
It’s nice to see things progressing, but there’s still a long way to go. In particular, as I said in my post about the missing features, there are quite a few features that still didn’t make it. In particular, I still miss:
We just have to wait for the next priorities of the team.