Attaching entities to EF context, without loading them, without sacrificing DDD

Question

In DDD it is customary to protect an entity's properties like this:

public class Customer
{
  private Customer() { }
  public Customer(int id, string name) { /* ...populate properties... */ }
  public int Id { get; private set; }
  public string Name { get; private set; }
  // and so on...
}

EF uses reflection so it can handle all those privates.

But what if you need to attach an entity without loading it (a very common thing to do):

var customer = new Customer { Id = getIdFromSomewhere() };       // can't do this!
myContext.Set<Customer>().Attach(customer);

This won't work because the Id setter is private.

What is a good way to deal with this mismatch between the language and DDD?

Ideas:

• make Id public (and break DDD)
• create a constructor/method to populate a dummy object (makes no sense)
• use reflection ("cheat")
• ???

I think the best compromise, is to use reflection, and set that private Id property, just like EF does. Yes it's reflection and slow, but much faster than loading from the database. And yes it's cheating, but at least as far as the domain is concerned, there is officially no way to instantiate that entity without going through the constructor.

How do you handle this scenario?

---

PS I did a simple benchmark and it takes about 10s to create a million instances using reflection. So compared to hitting the database, or the reflection performed by EF, the extra overhead is tiny.

Answer 1

"customary" implicitly means it's not a hard set rule, so if you have specific reasons to break those rules in your application, go for it. Making the property setter public would be better than going into reflection for this: not only because of performance issues, but also because it makes it much easier to put unwanted side-effects in your application. Reflection just isn't the way to deal with this.

But I think the first question here is why you would want the ID of an object to be set from the outside in the first place. EF uses the ID primarily to identify objects and you should not use the ID for other logic in your application than just that.

Assuming you have a strong reason to want to change the ID, I actually think you gave the answer yourself in the source you just put in the comments:

So you would have methods to control what happens to your objects and in doing so, constrain the properties so that they are not exposed to be set or modified “willy nilly”.

You can keep the private setter and use a method to set the ID.

EDIT: After reading this I tried doing some more testing myself and you could have the following:

public class Customer
{
  private Customer() { }
  public Customer(int id) { /* only sets id */ }
  public Customer(int id, string name) { /* ...populate properties... */ }
  public int Id { get; private set; }
  public string Name { get; private set; }
  // and so on...

  public void SetName(string name)
  {
      //set name, perhaps check for condition first
  }
}

public class MyController
{
    //...
    var customer = new Customer(getIdFromSomewhere());
    myContext.Set<Customer>().Attach(customer);
    order.setCustomer(customer);
    myContext.SaveChanges(); //sets the customer to order and saves it, without actually changing customer: still read as unchanged.
    //...
}

This code leaves the private setters as they were (you will need the methods for editing of course) and only the required changes are pushed to the db afterwards. As is also explained in the link above, only changes made after attaching are used and you should make sure you don't manually set the state of the object to modified, else all properties are pushed (potentially emptying your object).

Answer 2

This is what I'm doing, using reflection. I think it's the best bad option.

var customer = CreateInstanceFromPrivateConstructor<Customer>();
SetPrivateProperty(p=>p.ID, customer, 10);
myContext.Set<Customer>().Attach(customer);

//...and all the above was just for this:
order.setCustomer(customer);
myContext.SaveChanges();

The implementations of those two reflection methods aren't important. What is important:

• EF uses reflection for lots of stuff
• Database reads are much slower than these reflection calls (the benchmark I mentioned in the question shows how insignificant this perf hit is, about 10s to create a million instances)
• Domain is fully DDD - you can't create an entity in a weird state, or create one without going through the constructor (I did that above but I cheated for a specific case, just like EF does)