views:

330

answers:

1

I want to write a business object layer in a way that makes each entity object responsible for saving its own changes.

I thought it would be a good way to have each entity posses its own ObjectContext, attach itself to that ObjectContext and perform the transaction whenever it needs to be saved.

In LINQ to SQL, DataContext is very lightweight and thus my solution doesn't have too much memory consumption and performance loss. Is it the same with the ObjectContext?

And what about attaching objects? Is it a heavy unit of work like LINQ to SQL or not?

+1  A: 

It has been argued that objects shouldn't be responsible for this; their job is to represent instantiated object; it is the job of another (repository) class to persist it.

ObjectContext can be a pain when it comes to attaching/detaching objects, since (unlike LINQ-to-SQL) there is a much tighter coupling between the context and the entity. Personally, I wouldn't use this approach; I'd use the entity itself (or a working copy) as a transient unit of work along with a short-lived context.

Marc Gravell
1. Where has this issue been argued?
Mohammadreza
Anywhere that mentions "persistence ignorance" and "separation of concerns"; also with DI/IoC implications for testing. Of course, EF doesn't **allow** persistance ignorance, but that is another issue.
Marc Gravell