Should entities save/update themselves?

Hi,
In typical DDD application Services call entities methods to change 
some business state (for example, productService calls 
Product.changeName() to change the product name) and in the end those 
changes should be persisted to some data source. There are two 
options to persist the data (with respect to whom is responsible for 
that): 
(1) The service is calling some data provider to save/update the 
entity after all the changes

(2) The entity itself is being injected with some data provider class 
(via interface, e.g. IDao) and the entity can save/update itself: 
myDAO.update(this).

The first method make the entity completly agnostic to data sources. 
However the second method allows the entity to perform tomic 
operations and to decide when persisting should take place.

Which of the aforementioned methods do you prefer? is there any 
common/recommended way for that pattern?

Thanks.

------------------------------------

Re: Should entities save/update themselves?

Re: Should entities save/update themselves?

johnygold wrote:
> In typical DDD application Services call entities methods to change
> some business state (for example, productService calls
> Product.changeName() to change the product name) and in the end those
> changes should be persisted to some data source. There are two
> options to persist the data (with respect to whom is responsible for
> that):
> (1) The service is calling some data provider to save/update the
> entity after all the changes
> 
> (2) The entity itself is being injected with some data provider class
> (via interface, e.g. IDao) and the entity can save/update itself:
> myDAO.update(this).
> 
> The first method make the entity completly agnostic to data sources.
> However the second method allows the entity to perform tomic
> operations and to decide when persisting should take place.
> 
> Which of the aforementioned methods do you prefer? is there any
> common/recommended way for that pattern?

Here's how we do it in Qi4j(.org):
All work on Entities is done through a UnitOfWork. When a client begins 
a process it creates a UnitOfWork, which it then can use to lookup 
entities by id or through queries. All returned Entities are managed and 
registered in the UoW. When the client process is complete (and it may 
be a "long" or "short" transaction) it calls complete() on the UoW at 
which point the UoW will sync the state down to the underlying store(s), 
potentially using Transactions.

This way the Entities themselves are unaware of persistence, and it is 
the client who is responsible for properly delineating where a process 
begins and ends. Since all access is done through UoW's it also becomes 
trivial to implement the store as a batch interface (i.e. it deals with 
creating/updating/removing lists of objects rather than single ones), 
which potentially improves performance.

Sample code:
// Create new UoW
UnitOfWork uow = uowFactory.newUnitOfWork();

// Get reference to Entity
Order order = uow.getReference("1234",Order.class);

// Update state, through Property object
order.comment().set("Customer wants it to be sent to home address");

// UoW is done, sync with underlying store(s)
uow.complete();

/Rickard

------------------------------------

Re: Should entities save/update themselves?

Re: Should entities save/update themselves?

Thanks for your replies, i'm still not sure why entities should be 
unaware of the need to save/commit themself after some change.
From the rational point, it seems logical to me for an entity to call
"save()" on some provider when some change is finished (for example
when product entity finish to change its name, it calls IDao.save. 
This provider is just an interface for the entity which represent a 
place to commit transactions. The interface IDao might do nothing 
when reusing the entity in another application boundary, for example 
on application without DB.

Moreover, there are situation when aggregate entity must persist 
changses during some process (not in the end) , otherwise the 
operation won't be atomic. For example, when aggregate entity is 
performing changes in collection of childs it might be neccesary to 
save changes after each single change.

Will be glad to hear your opinion.

--- In domaindrivendesign <at> yahoogroups.com, Rickard �berg 
<rickardoberg@...> wrote:
>
> johnygold wrote:
> > In typical DDD application Services call entities methods to 
change
> > some business state (for example, productService calls
> > Product.changeName() to change the product name) and in the end 
those
> > changes should be persisted to some data source. There are two
> > options to persist the data (with respect to whom is responsible 
for
> > that):
> > (1) The service is calling some data provider to save/update the
> > entity after all the changes
> > 
> > (2) The entity itself is being injected with some data provider 
class
> > (via interface, e.g. IDao) and the entity can save/update itself:
> > myDAO.update(this).
> > 
> > The first method make the entity completly agnostic to data 
sources.
> > However the second method allows the entity to perform tomic
> > operations and to decide when persisting should take place.
> > 
> > Which of the aforementioned methods do you prefer? is there any
> > common/recommended way for that pattern?
> 
> Here's how we do it in Qi4j(.org):
> All work on Entities is done through a UnitOfWork. When a client 
begins 
> a process it creates a UnitOfWork, which it then can use to lookup 
> entities by id or through queries. All returned Entities are 
managed and 
> registered in the UoW. When the client process is complete (and it 
may 
> be a "long" or "short" transaction) it calls complete() on the UoW 
at 
> which point the UoW will sync the state down to the underlying store
(s), 
> potentially using Transactions.
> 
> This way the Entities themselves are unaware of persistence, and it 
is 
> the client who is responsible for properly delineating where a 
process 
> begins and ends. Since all access is done through UoW's it also 
becomes 
> trivial to implement the store as a batch interface (i.e. it deals 
with 
> creating/updating/removing lists of objects rather than single 
ones), 
> which potentially improves performance.
> 
> Sample code:
> // Create new UoW
> UnitOfWork uow = uowFactory.newUnitOfWork();
> 
> // Get reference to Entity
> Order order = uow.getReference("1234",Order.class);
> 
> // Update state, through Property object
> order.comment().set("Customer wants it to be sent to home address");
> 
> // UoW is done, sync with underlying store(s)
> uow.complete();
> 
> /Rickard
>

------------------------------------

Re: Should entities save/update themselves?

Re: Re: Should entities save/update themselves?

When entities are changed, most of the time a lot of external things
should change as well (like the database or the GUI). Therefore I
always use events to say that something is changed. The problem here
is to register the event handler to the entities on the right time..

For me the reason not to call a save/commit is that a database or the
database layer could change. When this happens, the domain should be
changed as well.

David

On Wed, Apr 2, 2008 at 11:33 AM, johnygold <johnygold <at> yahoo.com> wrote:
> Thanks for your replies, i'm still not sure why entities should be
>  unaware of the need to save/commit themself after some change.
>  From the rational point, it seems logical to me for an entity to call
>  "save()" on some provider when some change is finished (for example
>  when product entity finish to change its name, it calls IDao.save.
>  This provider is just an interface for the entity which represent a
>  place to commit transactions. The interface IDao might do nothing
>  when reusing the entity in another application boundary, for example
>  on application without DB.
>
>  Moreover, there are situation when aggregate entity must persist
>  changses during some process (not in the end) , otherwise the
>  operation won't be atomic. For example, when aggregate entity is
>  performing changes in collection of childs it might be neccesary to
>  save changes after each single change.
>
>  Will be glad to hear your opinion.
>
>  --- In domaindrivendesign <at> yahoogroups.com, Rickard �berg
>
>
> <rickardoberg@...> wrote:
>  >
>  > johnygold wrote:
>  > > In typical DDD application Services call entities methods to
>  change
>  > > some business state (for example, productService calls
>  > > Product.changeName() to change the product name) and in the end
>  those
>  > > changes should be persisted to some data source. There are two
>  > > options to persist the data (with respect to whom is responsible
>  for
>  > > that):
>  > > (1) The service is calling some data provider to save/update the
>  > > entity after all the changes
>  > >
>  > > (2) The entity itself is being injected with some data provider
>  class
>  > > (via interface, e.g. IDao) and the entity can save/update itself:
>  > > myDAO.update(this).
>  > >
>  > > The first method make the entity completly agnostic to data
>  sources.
>  > > However the second method allows the entity to perform tomic
>  > > operations and to decide when persisting should take place.
>  > >
>  > > Which of the aforementioned methods do you prefer? is there any
>  > > common/recommended way for that pattern?
>  >
>  > Here's how we do it in Qi4j(.org):
>  > All work on Entities is done through a UnitOfWork. When a client
>  begins
>  > a process it creates a UnitOfWork, which it then can use to lookup
>  > entities by id or through queries. All returned Entities are
>  managed and
>  > registered in the UoW. When the client process is complete (and it
>  may
>  > be a "long" or "short" transaction) it calls complete() on the UoW
>  at
>  > which point the UoW will sync the state down to the underlying store
>  (s),
>  > potentially using Transactions.
>  >
>  > This way the Entities themselves are unaware of persistence, and it
>  is
>  > the client who is responsible for properly delineating where a
>  process
>  > begins and ends. Since all access is done through UoW's it also
>  becomes
>  > trivial to implement the store as a batch interface (i.e. it deals
>  with
>  > creating/updating/removing lists of objects rather than single
>  ones),
>  > which potentially improves performance.
>  >
>  > Sample code:
>  > // Create new UoW
>  > UnitOfWork uow = uowFactory.newUnitOfWork();
>  >
>  > // Get reference to Entity
>  > Order order = uow.getReference("1234",Order.class);
>  >
>  > // Update state, through Property object
>  > order.comment().set("Customer wants it to be sent to home address");
>  >
>  > // UoW is done, sync with underlying store(s)
>  > uow.complete();
>  >
>  > /Rickard
>  >
>
>
>
>  ------------------------------------
>
>  Yahoo! Groups Links
>
>
>
>

------------------------------------

Yahoo! Groups Links

<*> To visit your group on the web, go to:
    http://groups.yahoo.com/group/domaindrivendesign/

<*> Your email settings:
    Individual Email | Traditional

<*> To change settings online go to:
    http://groups.yahoo.com/group/domaindrivendesign/join
    (Yahoo! ID required)

<*> To change settings via email:
    mailto:domaindrivendesign-digest <at> yahoogroups.com 
    mailto:domaindrivendesign-fullfeatured <at> yahoogroups.com

<*> To unsubscribe from this group, send an email to:
    domaindrivendesign-unsubscribe <at> yahoogroups.com

<*> Your use of Yahoo! Groups is subject to:
    http://docs.yahoo.com/info/terms/

Re: Re: Should entities save/update themselves?

Re: Should entities save/update themselves?

Re: Should entities save/update themselves?

David,
When your DB change - nothing changes in the Domain. It's the IDao 
implementaion (located in different package/project) which changes. 

Al,
1. About seperation of concern:
Theoretically entities deal only with the Domain logic ("isolate the 
domain"), but practically sometime there is no escape from technical 
tasks. A real life example i had: Product entity which has "validate" 
method - it performs some business logic , then checks that all it's 
resources (images, custom files) are indeed on the physical disc, 
then continue with the business logic. The trade-off is between

(a) pure seperation of concern, preventing the Product entity from 
checking the disc and loosing it's ability to validate itself and 
perform atomic operation. It can indeed throw an event when the disc 
should be checked but then part of the validation will be external. 
After throwing an event, the entity will not know if the disc 
validation succeeded.

(b) atomic operation with minimal mixing of concern, the product 
entity is being inject with IPhysicalResourcesProvider which is being 
used to check the disc. This way all the validation phase is 
hapenning on the Product entity. And all it depends on is provider 
Interfaces. 

2. About saving/updating in many places:
You are right, the DB operation should be managed by some component 
who has birds-eye view on the transaction, but i think this should be 
the aggregate (Producy , in my case) and not the service. If the 
transaction is being shared by few aggregates, why won't you pass 
ITransaction to each aggregate?

Yoni

--- In domaindrivendesign <at> yahoogroups.com, "Alasdair Gilmour" 
<alasdairg@...> wrote:
>
> IMHO, its just down to separation of concerns and the Single 
Responsibility
> Principle: A Product entity represents a specific business concept 
in the
> domain. Saving an object's state to the database is a completely 
orthogonal
> responsibility that is nothing to do with "being a Product", so it 
doesn't
> conceptually belong within the Product entity.
> 
> Moreover, within an application, an entity can be changed from many
> different places as part of many different use cases. Since an 
entity can
> not know what particular application use case it is being 
manipulated for,
> how can it know when it is the right time to call save? As a very 
simple
> example, if a use case were to change a Product's name and then 
immediately
> its product number, I wouldn't want to call save() on both the name 
change
> and the product number change - but just once when all the changes 
for that
> particular use case had been made ....
> 
> Anyway, just my 2c
> 
> Al
> 
> > Thanks for your replies, i'm still not sure why entities should be
> > unaware of the need to save/commit themself after some change.
> > From the rational point, it seems logical to me for an entity to 
call
> > "save()" on some provider when some change is finished (for 
example
> > when product entity finish to change its name, it calls IDao.save.
>

------------------------------------