I Use EF Code First, and lazy loading.
My problem relates to how to efficiently update an entity in within a grandchild collection. First of all, i fear this makes a lot of calls in the db that is not really needed. But if my domain class is not to care about persitance, I cant see another way to do this.
Here is the classes:
public class Supplier
{
public int Id {get;set;}
//...Supplier properties
public virtual ICollection<Contract> Contracts {get;set;}
//supplier methods
}
public class Contract
{
public int id {get;set;}
public int SupplierId{get;set;}
//---Contract properties
[ForeignKey("SupplierId")]
public virtual Supplier Supplier {get;set;}
public virtual ICollection<DeliveryContract> DeliveryContracts {get;set;}
}
public class DeliveryContract
{
public int Id {get;set;}
public bool DeliveryOnMonday{get;set;}
public bool DeliveryOnTuesday{get;set}
//...30 different Delivery terms properties
public Department Department {get;set;}
public int ContractId {get;set;}
[ForeignKey("ContractId")
public virtual Contract Contract {get;set;}
}
The Supplier is the aggregate Root. So i have a method on the supplier which is ChangeDeliveryContract, and that corresponds to what would happen in the real world.
public class Supplier
{
//properties
public void ChangeDeliveryContract (DeliveryContract cahangedDc)
{
//So from the supplier i have to find the contract to change
var dcToUpdate = Contracts
.SingleOrDefault(c=>c.Id == changedDc.ContractId)
.SingleOrDefalut(dc=>dc.Id == changedDc.Id);
//So... what do i do now? Map all 30 properties from changedDc to DcToUpdate
//Some business rules is also applied here i.e. there can only be one
// DeliveryContract between Supplier and Department
}
}
I use MVC so the program would look something like: public ActionResult Update (DeliveryContract changedDc, int supplierId)
{
var Supplier = supplierRepository.GetById(supplierid);
supplier ChangeDeliveryContract (changedDc);
supplierRepository.Save();
//More code...
}
First of all, the problem lays in the ChangeDeliveryContract. I've not been able to get this to work. Also, i feel querying through collections like I do might be inefficient. Third, mapping 30 + properties also feels a bit wrong.
How do you guys do it, and is there a best practices here.
In applying DDD, the selection of aggregate roots can vary depending on various characteristics of the model, which include considerations regarding the number of children, etc. In this case, while Supplier is an AR, it does not mean that DeliveryContract can't also be an AR. While it may seem like Supplier is the sole AR and all operations regarding suppliers should stem from the Supplier class, this can become unruly with respect to database calls as you've come to realize. One role of an AR is the protection of invariants and there is nothing on the Supplier class that is used to protecting invariants which is a possible indication that Supplier is not the most appropriate AR to implement the required business rules. Therefore, it seems to me that in this case you can make DeliveryContract an AR, with its own repository, and a method for applying changes. Or you can make Contract an AR, depending on whether a contract must enforce any invariants regarding delivery contracts and also on a practical consideration of the number of expected delivery contracts per contract. If the number is very high, then it would be impractical to have a collection of delivery contracts on the contract class. Overall, I would opt for having smaller ARs, though invariants and consistency rules must be considered.
Take a look at a great series of articles by Vaughn Vernon for an in-depth treatment of this topic: Effective Aggregate Design.