CODEWITHSUNDEEP
repositorydomain-driven-designgetter
csherriff
csherriff

Reputation: 113

DDD Object Persistence without Getters

I think I'm missing something really obvious but there is a lot of disagreement on domain objects and their persistence via a repository so it's hard to get a clear answer on this.

Assuming that

If avoid exposing getters (and definitely not setters) then how does my repository get access to the state of the object in order to actually persist it.

Options??

  1. Dependency injection into the domain model (DDD smell??)

  2. Getters only (DDD smell??)

Also there is the reverse issue pulling objects out of the DB. Initialisation via the constructor seems the only likely candidate.

Upvotes: 7

Views: 1191

Answers (2)

Eben Roux
Eben Roux

Reputation: 13256

As eulerfx has stated: since you are using an ORM you have to use what it provides.

I will never willingly use an ORM so my experience is somewhat limited but it does seem to be an issue in that the ORM makes its way into the object model in some form or another. In some instances it forces you to design you classes in a particular way.

That being said. In order to persist an object you need its state. In order to hydrate an object you need to provide it its state. There is just no way around that bit. If your tooling requires getters and setters then so be it.

You may have some state object that is exposed/consumed by your object and even though the intention is somewhat clearer it just moves the problem --- but it is probably better :).

Even with event sourcing the events contain the state and have to be applied to the object to get it back to its last state or you could use a snapshot that is exactly the same as a state object.

Public getters and setters are somewhat open to abuse but it is what it is.

Upvotes: 2

eulerfx
eulerfx

Reputation: 37739

An ORM can get to the data inside objects via reflection. For example, NHibernate has various access strategies for properties which allow mapped classes to only have private fields with no getters or setters. I think EF should have similar facilities.

Upvotes: 2

Related Questions