Below is the Project code-first class mapped directly to the database through the Entity Framework 6 Fluent API:
public class Project
{
public Project()
{}
public int ProjectId { get; set; }
public string Name { get; set; }
public bool IsActive { get; set; }
public ICollection<ProjectVersion> ProjectVersions { get; set; }
}
Anemic models in Domain-Driven Design are an anti-pattern. I want to use this same class in my domain model instead of creating a separate Project
domain class and having to perform complicated mapping between the two in the repository (and with the hundreds of other models we have).
This is how Project
would look as a domain model class:
public class Project
{
private readonly List<ProjectVersion> projectVersions;
public Project(string name, string description)
{
Name = name;
Description = description;
projectVersions = new List<ProjectVersion>();
}
public int ProjectId { get; private set; }
public string Name { get; set; }
public bool IsActive { get; private set; }
public IEnumerable<ProjectVersion> ProjectVersions
{
get
{
return projectVersions;
}
}
public void AddVersion(ProjectVersion version)
{
projectVersions.Add(version);
}
}
From what I have read, I am able to map to a private fields with EF's Fluent API.
Are there any any shortcomings here? Am I taking an unnecessary shortcut?
The only problem I can forsee is when a business domain model would essentially consist of data from two or more data entities.
I think you're making a mistake in this approach. I think you should separate the concerns of your Domain models from the concerns of your Entity models. Uncle Bob wrote a strange, but on-point blog post about this here: Dance You Imps! (seriously, it's a weird post.) The ORM's job is to act as a contract to your database. Your domain models' job is to provide the functionality. In short, you should let Entity Framework function the way it wants to. If you want to do DDD, write a mapping layer to convert EF models to your Domain models.