Tag Archives: DDD

DDD Fundamentals, SOON SOON

imageSteve Smith and I have been working for quite a while on a Domain-Driven Design Fundamentals course for Pluralsight. Our schedules and some interesting, unexpected but quite welcome, learning curves and most importantly, our “go big or go home” desire to refine, clarify and polish everything made this take longer to finish than either of us imagined.

In addition, the demo app that we show and evolve throughout the course – much of which is Steve’s genius – is totally kick-ass!

We are grateful that Eric Evans participated in this by chatting with us on Skype and capturing video to include throughout the course. We also are thankful for some guidance from another DDD guru, Vaughn Vernon.

The course is about 4.5 hours long, broken up into 7 modules.

The course has been done, reviewed, edited and absolutely final…ready to be published but unfortunately, so are many other new courses on Pluralsight. So the DDD Fundamentals is in the queue to get published soon.

Believe me, Steve & I will be tweeting up a storm when this thing finally goes live so watch our blogs or twitter (I’m twitter.com/julielerman, he’s twitter.com/ardalis).

First look at (beta of) EF 6.1 Designer

EF6.1 is closing in on release. Along with the new DLLs that you can get via Nuget, there is a new designer that you can install into Visual Studio 2012 or 2013 via an MSI install.

Before installing, I uninstalled the EF Power Tools, because I wasn’t sure if they were included. Post install of the 6.1 Beta EF Designer, there was no indication of the power tool features in my context menu where it would normally be.

image

So it looks like this iteration of the designer won’t have the power tool features wrapped in except for the BIG one, the replacement of the reverse engineer into code first.  (So don’t uninstall those power tools! You can still use the other features like this one: my favorite).

With the new designer, when you create a new model, you now get 4 options. Two are familiar, EF Model from Database and Empty Model. The new ones are Empty Code First Model and Code First from database.

image

I chose Code First from database and pointed to AdventureWorks2012 and selected everything in the Human Resources schema.

image

This resulted in all of my new classes being created in my project, not in a folder.

image

Also, it added references to EF.

But the classes felt a little messy. So for my next model, I began with a new project folder. (note that I am only experimenting. I do not recommend having two models in the same project.)

image

Then I added the new entity model to th efolder, not the outer project. This time I selected the Person schema.

image

and all the new classes landed in my new folder

image

I prefer that. In a real app I would then separate the domain classes into their own projects and I would also put each of the models in its own project.

Let’s take a look at the domain classes that this generated.

Notice that tehre are data annotations. This is different than the EF Power Tools which put everything in fluent API code.

image

But those are annotations that are reasonable in a class since they are not solely defining a database mapping strategy.. required and stringlength can also be used by EF’s and .NET’s validation APIs. For the latter , think MVC validation.

But that’s not how this tool decides to use data annotations. Check the BusinessEntityAddress type.

image

It has annotations that drive the composite key creation and also that note database generated mappings. I wouldn’t normally put those in my domain types.

The rule that is being used by default is: any mappings that can be described with a data annotation are done that way. Everything else is done with a fluent api. None of my tables triggered any fluent api mappings. There is some discussion (started by guess who? Smile) on codeplex about making it easier to force the designer to use all fluent mappings if you want.

I was curious what Empty Code First Model gives us. It sets up a shell DbContext class. Makes sense to me.

image

I have been asking for the ability to select individual tables/views for reverse engineering an existing database into Code First context ad classes since the first public CTP of the EF Power Tools. (Here’s proof!) So even with a few things I’d like to see done differently, I am thrilled with this new designer feature.

Why?

For people building new apps with legacy databases, it is a great first step towards setting up DbContexts that  you can align with Domain Driven Design Bounded Contexts.  It gives me a nice stake in the ground to thinking within boundaries and also forcing me to think about when a customer in one context should be designed differently than a customer type in another context because they are used differently.

Any-hoo…there’s a quick first look for you. There’s still time to provide feedback to the team on the codeplex site. Go to this workitem: https://entityframework.codeplex.com/workitem/407

Also, as Erik reminds me in the comments, there is a  Visual Studio extension that provides some more extensive reverse engineer features into code first dbcontext and classes. You can find the docs, a video and the download here:  EntityFramework Reverse POCO Generator