Потребление и производительность памяти ObjectContext

Question

Я хочу написать слой бизнес-объекта таким образом, чтобы каждый объект объекта отвечал за сохранение собственных изменений.

Я думал, что это будет хороший способ иметь каждый объект, обладающий собственным ObjectContext, присоединяться к этому объекту ObjectContext и выполнять транзакцию всякий раз, когда ее нужно сохранить.

В LINQ to SQL DataContext очень легкий и, следовательно, мое решение не имеет слишком большого объема памяти и потери производительности. То же самое с ObjectContext?

А как насчет крепления объектов? Это тяжелая единица работы, такая как LINQ to SQL или нет?

Answer 1

Утверждается, что объекты не должны отвечать за это; их задача - представлять экземпляр объекта; это работа другого (хранилища) класса, чтобы сохранить его.

ObjectContext может быть больно, когда речь идет о прикреплении/отсоединении объектов, поскольку (в отличие от LINQ-to-SQL) существует гораздо более плотная связь между контекстом и объектом. Лично я бы не использовал этот подход; Я бы использовал сам объект (или рабочую копию) как временную единицу работы вместе с недолговечным контекстом.