In 2012, I published a course on Pluralsight called Entity Framework in the Enterprise. Since then I have learned so much, most importantly, I’ve become very active with Domain-Driven Design, even publishing the DDD Fundamentals course that I co-created with Steve Smith. This has had a big impact on how I think about designing and architecting software and in turn,how I approach incorporating EF in to large, complex applications.
I’ve been wanting to re-do that old course to share my new views. I finally began in January of this year, but had a 3 month conference travel hiatus. So while it feels like a baby that I spent 9 months on, it was really only 6 months. Still quite a long time!
In the course, I use VS2015 and EF6. Why EF6? Because EF Core is too new. Most of the patterns I discuss and demonstrate are totally applicable to EF Core. There is one thing that is not yet in EF Core: Value Objects, but that is coming. Also the module on testing focuses on mocking and does not take EF Core’s new In Memory provider into account. Other than that, you can use what you learn here with EF Core as well.
I put a lot of thought into this course and I think this comment on the discussion forum for the course expresses it so well:
I just watched Julie Lerman’s prior Entity Framework in the Enterprise three weeks ago, before this new course was released, and boy am I glad she’s updated the course. I had thought the previous version was a bit dated (2016 vs 2012 & EF6 vs EF4) and a bit basic with what Julie refers to as Demo Ware. This updated course goes into more details about architecting projects, improved Moq testing with EF6, and a better explanation of DDD with Bounded Contexts using Schema to segregate areas. I already had a good understanding of EF, DDD, Repositories, UoW, and CQRS before watching and while I wouldn’t set up things 100% this way in my own applications they did jump start some refactorings and rethinking on how I maintain my solution, which is the purpose of these courses, to give fresh ideas as technology evolves, just as Entity Framework has. Thanks for updating the course and for those who have watched the previous version, definitely give this new one a watch.
I wrote this in a Github issue thread about EFCore & lack of current support for complex types (which support DDD Value Objects .. to a degree) this morning and someone said I should share it so here it is:
I love value objects. I’m just not considering efcore for any serious work yet so I am not going to stress out about not using them. I find myself designing my domain with them out of habit then having to undo. And if you are set on efcore, then +++ to @jnm2 ‘s point. I map from domain to EF’s data model (the in-memory model that EF infers at runtime) using EF’s mapping when it’s easy and I don’t have to make annoying (or worse) concessions. Otherwise it is time for a mapper between domain and data model defined by separate classes + EF DBContext. So EF mapping layer is my default mapper when using EF. But sometimes it is just not sufficient and I go to (or recommend) the effort of building a separate data model. Your choice. Pick your battles.
Another point is that Jimmy Bogard doesn’t even think the ef6 complex types do enough to map types that you’ve defined as value objects. So he’s been either just using one to one or going the extra mapper route depending on the situation. Gogglebing Jimmy Bogard, something like “what’s missing in ef6 for DDD” to read more. And then there’s that collection conundrum, too as well as the problem of mapping private fields. So if you are okay without those in EF6, maybe support for value objects isn’t such a huge deal except for the problem of it being “taken away” temporarily.
I’m sharing because of the following reply from Joseph Musser on this thread:
I would love to have had (and still would love) an article that thoroughly addresses that question: weighing the pros and cons of staying within EF modeling constraints or using a data model and mapping yourself. When to consider making the switch. And what that means for creating a rich, disciplined model that doesn’t become anemic. I feel like I’ve wasted a lot of time not having a fundamental understanding of this from the beginning.
Even though the solution is available for download, it involves installing and running RabbitMQ and learning my way around the server’s UI. For me that was a fun and almost freeing step of building the solution. It even meant installing Erlang on my laptop. Lots of fun but lots of learning curves.
But it may be more than some readers want to commit to. So I recorded a video of me debugging through the solution so that you can see how it works.
I recommend reading the article first and watching the Domain-Driven Fundamentals course that Steve Smith and I created for Pluralsight will really help. If you don’t have a Pluralsight subscription yet (really?) send me a message through my contact form and I can hook you up with a free trial. Warning…can lead to addiction.
Anyway, here is the video. There is no sound…I’ve used captions to explain. [youtube http://www.youtube.com/watch?v=N55t2g0cRRQ?rel=0]