Здравствуйте, Sinix, Вы писали:

S>Второй раз один и тот же вопрос (http://www.rsdn.ru/Forum/message/3361137.1.aspx

Автор: Sinix
Дата: 14.04.09

).
Просто у меня янус три дня глючил и не отправлял ответы.
S>Второй раз отвечу что лучше по старинке:
S>

S>(from o in orders where o.OrderDate < xxx select o).
S>  Update(o => o.SetDelayed(true)).
S>  Update(o => SetDiscount(o.discount + Consts.DelayDiscountRate)); // кстати чисто в теории такие методы вполне можно мапить на хранимые процедуры - вообще ляпота будет.
S>

S>Проще парсить expression tree.
S>Да и в концепцию IQueryable лучше вписывается.
В принципе, да. Я не против . Всё равно в основе лежит Expr<Func<T, T>>.
Альтернативный подход построен на Expr<Action<T>>, и выковыривании изменений, примененных к объекту "по месту". (...UpdateAll(o=>{o.Name = "Vasya";})).
Этот подход ближе к помыслам ORM-щиков; мне он принципиально не нравится, т.к. позволяет скомпилировать код, меняющий состояние объектов вне контекста UpdateAll, что полностью противоречит идее явных апдейтов.
Впрочем, Wayward вроде придумал механику, которая позволяет совместить оба подхода в рамках достаточно худенького IUpdatable<T>.
http://blogs.msdn.com/mattwar/archive/2009/01/22/building-a-linq-iqueryable-provider-part-xiii-iqtoolkit-v-0-13.aspx