How to avoid persistence logic in domain model?

Question

My domain model looks like this:

class Group
{
    private List<Person> persons;

    public void AddPerson(Person p) {
       persons.Add(p);
       DoSideEffect()
    }

    public List<Person> GetPersons() {...}
}

Now I need to persist it. By DDD I cannot add any persistence attributes to this class so xml serializers will not work. BinaryFormatter cannot be used since the format should be readable. I can manually call GetPersons() and persist them - but how am I going to load them back? If I call AddPerson() then there is a side effect. The side effect should only happen when a person is "really" added to the domain, not with persistrancy.

score 3 · Accepted Answer · answered Jun 11 '12 at 13:55

I realize this post is old but it still remains unanswered, so here it goes:

The key here is that your model is flawed, imo.

Group should be a domain object with a simple read-only collection of 'persons' (members?). Responsibility for retrieving and persisting the Group belongs to the GroupRepository which with load the data from your persistence store and reconstitute the object.

For example:

public class Group
{
    private Collection<Person> _persons;

    public Group(Collection<Person> persons)
    {
        if (persons == null)
            throw new ArgumentNullException("persons");

        _persons = persons;    
    }

    public IEnumerable<Person> Persons
    {
        get { return _persons; }
    }

    public void AddPerson(Person p)
    {
        if (p == null)
            throw new ArgumentNullException("p");

        _persons.Add(p);
        DoSideAffect();
    }
}

public class GroupRepository
{
    public Group FindBy(Criteria c)
    {
        // Use whatever technology (EF, NHibernate, ADO.NET, etc) to retrieve the data

        var group = new Group(new Collection<Person>(listOfPersonsFromDataStore));

        return group;
    }

    public void Save(Group g)
    {
        // Use whatever technology to save the group
        // Iterate through g.Persons to persist membership information if needed
    }
}

Use a dependency injection framework (Spring.NET, MEF, Unity, etc.) and create an IGroupRepository interface which can be injected in your application code to retrieve and persist your Group domain objects.

score 0 · Answer 2 · answered Oct 17 '10 at 19:30

0

Lack of attributes isn't a show-stopper; XmlSerializer has a constructor to pass in this model at runtime ( but to be honest, most times the defaults are fine) - as so several other serializers. XML via XmlSerializer is obviously desirable if readability is a concern though. See XmlAttributeOverrides. I can also suggest some binary serializers that would work here.

answered Oct 17 '10 at 19:30

Marc Gravell

1,026,079
266
2,566
2,900

@Yaron; ah, no, it can't. DataConractSerializer *can* though. As can protobuf-net "v2" if you don't mind binary. I know the latter supports attribute-less models ('cos I wrote it). – Marc Gravell Oct 17 '10 at 19:36
@Yaron - the other approach is a dedicated DTO layer. – Marc Gravell Oct 17 '10 at 19:37
I want the DTO (for various other reasons too). It still has the same problem - the only way to add a person is by causing the side-effect (see my code). For loading (persistance) I do not want the side effect to happen - no person is "really" added, I just load a previous state. Sure, I can expose a method that adds a person w/o the effect - but this adds persistance helper code to domain model... – Yaron Naveh Oct 17 '10 at 19:42

How to avoid persistence logic in domain model?

2 Answers2