CODEWITHSUNDEEP
c#entity-frameworkrepositorydomain-driven-design
Vinicius Gonçalves
Vinicius Gonçalves

Reputation: 2724

Save related entities in DDD

I've the following service operation in my ICustomerService:

public void RegisterCustomer(Customer customer)
{
    Check.NotNull(customer, "customer");

    //do another domain specific things...

    customerRepository.Save(customer);
}

Edit

Customer class has an reference to ICollection<> of CustomerAddress entity.
This operation have to save customer address list too.

I know that do cascade updates does not is a good thing in this scenario:

How should I handle persistence for referenced entities?

From the DDD perspective, how should i do in this case?
Should i ask customer address list to the service operation through parameter?

Upvotes: 0

Views: 818

Answers (2)

guillaume31
guillaume31

Reputation: 14064

I know that do cascade updates does not is a good thing in this scenario:

Why ? As long as CustomerAddress is a simple entity and not an Aggregate Root, you have everything to gain by letting EF persist them along with the Customer.

Judging by your other question too, I think you may miss the Aggregate Root vs Entity distinction. This is where you should start -- design your aggregates, decide which objects should be AR's, simple Entities and Value Objects.

From there everything should fall into place according to some simple rules : one Repository per AR, Entities can only have references to Entities from the same Aggregate, it's better if an AR references another AR by its ID only, and VO's can be referenced from anywhere.

Upvotes: 2

Sattar Imamov
Sattar Imamov

Reputation: 572

If you ask CustomerPhone, you can break (or not? it depends) invariant of Customer object. One of approaches is use Memento pattern. Extract internal state of your Customer to Memento object and pass this Memento to repository.

Upvotes: 0

Related Questions