Entity Framework – Avoiding the Anemic Domain Model

business-logiccdomain-modelentity-framework

In our business logic we occasionally have methods defined something like this:

User.ResetCourse(Course courseToReset)

The problem is that both User and Course are Entity Framework proxy objects. This means that when we hit navigation properties on either User or Course it can cause a huge hit to the database because those objects are not IQueryable so it iterates through them normally.

To solve this we changed the signature to:

User.ResetCourse(MyDBContext db, Course courseToReset)

This means we can directly query the database to make the changes we need in an efficient manner but passing the Database context to a business object just seems so wrong.

We later migrated to user a service layer which means we have something like:

CourseService.ResetForUser(Course courseToReset, User forUser)

This service has a reference to the DBContext injected in on creation but now our business objects are just data bags with no behaviour (i.e an Anemic Domain Model).

How can we avoid this?

Best Answer

The issue is, you are using EF objects as domain objects in the first place. EF objects are data models NOT business models.

You need to declare business objects which give you the freedom to do as you need, and then retrieve and store them with a repository. Your repository will map the EF entities to your business entities. EF objects should never be used outside of your repositories.

Related Solutions

Entity Framework – Is It Suitable for Our Situation?

As far as versioning goes, I'll tell you that you already have this problem in a different form, though you might not know it. You have one database, but you have multiple projects accessing the data, correct? Essentially what's happening now is that since you are (probably) using SQL to access your database in each of your applications your project still compiles no matter what changes you've made to the database. Any truly breaking changes happen at runtime.

By adding an entity data model, you merely shift this break in your application to one that happens at compile-time. I guess my question back at you is "how are you versioning your database changes?" I would suggest you create a single entity data model, package it into an assembly, and make changes to it as you make changes to your database. Use branching and merging in your source control provider to manage how these changes actually happen in your development workflow. The newer versions of the Entity Framework are a lot better nowadays for managing merges than they used to be.

C# – S.O.L.I.D., avoiding anemic domains, dependency injection

I would say that neither a person nor a vehicle should know whether a payment is due.

reexamining the problem domain

If you look at the problem domain "people having cars": In order to purchase a car you have some sort of contract which transfers ownership from one person to the other, neither the car nor the person change in that process. Your model is completely lacking that.

thought experiment

Assuming there is a married couple, the man owns the car and he is paying the taxes. Now the man dies, his wife inherits the car and will pay the taxes. Yet, your plates will stay the same (at least in my country they will). It is still the same car! You should be able to model that in your domain.

=> Ownership

A car that is not owned by anyone is still a car but nobody will pay taxes for it. In fact, you are not paying taxes for the car but for the privilege of owning a car. So my proposition would be:

public class Person
{
    public string Name { get; set; }

    public string Surname { get; set; }

    public List<Ownership> getOwnerships();

    public List<Vehicle> getVehiclesOwned();
}

public abstract class Vehicle
{
    public string PlateNumber { get; set; }

    public Ownership currentOwnership { get; set; }

}

public class Car : Vehicle {}

public class Motorbike : Vehicle {}

public abstract class Ownership
{
    public Ownership(Vehicle vehicle, Owner owner);

    public Vehicle Vehicle { get;}

    public Owner CurrentOwner { get; set; }

    public abstract bool HasToPay();

    public DateTime LastPaidTime { get; set; }

   //Could model things like payment history or owner history here as well
}

public class CarOwnership : Ownership
{
    public override bool HasToPay()
    {
        return (DateTime.Today - this.LastPaidTime).TotalDays >= 30;
    }
}

public class MotorbikeOwnership : Ownership
{
    public override bool HasToPay()
    {
        return (DateTime.Today - this.LastPaidTime).TotalDays >= 60;
    }
}

public class PublicAdministration
{
    public IEnumerable<Ownership> GetVehiclesThatHaveToPay()
    {
        return this.GetAllOwnerships().Where(HasToPay());
    }

}

This is far from perfect and probably not even remotely correct C# code but I hope you get the idea (and somebody could clean this up). The only downside is that you would probably need a factory or something to create the correct CarOwnership between a Car and a Person