Page 14 - MSDN Magazine, September 2017

Data Points JULIE LERMAN DDD-Friendlier EF Core 2.0
If you’ve been following this column for a while, you may have noticed quite a few articles about implementing Entity Framework (EF) when building solutions that lean on Domain-Driven Design (DDD) patterns and guidance. Even though DDD is focused on the domain, not on how data is persisted, at some point you need data to flow in and out of your software.
In past iterations of EF, its patterns (conventional or customized) have allowed users to map uncomplicated domain classes directly to the database without too much friction. And my guidance has generally been that if the EF mapping layer takes care of getting your nicely designed domain models into and out of the database with- out having to create an additional data model, this is sufficient. But at the point when you find yourself tweaking your domain classes and logic to make them work better with Entity Framework, that’s a red flag that it’s time to create a model for data persistence and then map from the domain model classes to the data model classes.
I was a little surprised to realize how long ago those articles about DDD and EF mappings came out. It’s been four years since I wrote the three-part series called “Coding for Domain-Driven Design: Tips for Data-Focused Devs,” which span the August, September and October 2013 issues of MSDN Magazine. Here’s a link to the first part, which includes links to the entire series: msdn.com/magazine/dn342868.
There were two specific columns that addressed DDD patterns and explained how EF did or didn’t easily map between your domain classes and database. As of EF6, one of the biggest issues was the fact that you couldn’t encapsulate and thereby protect a “child” collection. Using the known patterns for protecting the col- lection (most often this meant employing an IEnumerable) didn’t align with EF’s requirements, and EF wouldn’t even recognize that the navigation should be part of the model. Steve Smith and I spent a lot of time thinking about this when we created our Pluralsight course, Domain-Driven Design Fundamentals (bit.ly/PS-DDD) and eventually Steve came up with a nice workaround (bit.ly/2ufw89D).
EF Core finally solved this problem with version 1.1 and I wrote about this new feature in the January 2017 column (msdn.com/magazine/ mt745093). EF Core 1.0 and 1.1 also resolved a few other DDD con- straints but left some gaps—most notably the inability to map DDD value objects used in your domain types. The ability to do this had existed in EF since its beginning, but it hadn’t yet been brought to EF Core. But with the upcoming EF Core 2.0, that limitation is now gone.
What I’m going to do in this article is lay out the EF Core 2.0 fea- tures available to you that align with many of the DDD concepts. EF Core 2.0 is much friendlier to developers who are leveraging these concepts and perhaps it will introduce you to them for the first time. Even if you don’t plan to embrace DDD, you can still benefit from its many great patterns! And now you can do that even more with EF Core.
One-to-One Gets Smarter
In his book, “Domain-Driven Design,” Eric Evans says, “A bidirec- tional association means that both objects can be understood only together. When application requirements do not call for traversal in both directions, adding a traversal direction reduces inter- dependence and simplifies the design.” Following this guidance has indeed removed side effects in my code. EF has always been able to handle uni-directional relationships with one-to-many and one- to-one. In fact, while writing this article, I learned that my longtime misunderstanding that a one-to-one relationship with both ends required forces you into a bi-directional relationship was wrong. However, you did have to explicitly configure those required relationships, and that’s something you don’t have to do now in EF Core, except for with edge cases.
EF Core should be able to correctly infer the dependent end of the relationship based on the foreign key property.
An unfavorable requirement in EF6 for one-to-one relationships was that the key property in the dependent type had to double as the foreign key back to the principal entity. This forced you to design classes in an odd way, even if you got used to it. Thanks to the introduction of support for unique foreign keys in EF Core, you can now have an explicit foreign key property in the depen- dent end of the one-to-one relationship. Having an explicit foreign key is more natural. And in most cases, EF Core should be able to correctly infer the dependent end of the relationship based on the existence of that foreign key property. If it doesn’t get it right
Code download available at bit.ly/2tDRXwi.
10 msdn magazine