CODEWITHSUNDEEP
.netlinqlinq-to-sqlentity-framework
mrtaikandi
mrtaikandi

Reputation: 6948

ObjectContext memory consumption and performance

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?

Upvotes: 2

Views: 817

Answers (1)

Marc Gravell
Marc Gravell

Reputation: 1062660

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.

Upvotes: 2

Related Questions