VD>>>У тебя мозг уже работает только в условиях одной парадигмы. Объяснить тебе что-то невозможно, так как ты просто не хочешь воспринять наличие другой парадигмы.

J>>Нет.

VD>Уверяю тебя. Ты знаком хотя бы с одним функциональным языком? Чувствую, что нет.

Знаком с Haskell.

VD>Так вот попробуй изучить. Уверяю тебя, что крышу будет рвать не по детски. А меж тем ничего сложного там нет. Просто несоответствие межд тем как ты видишь мир вычислений и тем как ее представляет модель ФП.
VD>Вот та же байда и здесь.

Я не вижу прямой связи между ФП и тем, о чем мы сейчас говорим. В функциональном языке тоже можно вынуть список Customer-оа, переработать его в другой список Customer-ов и потом запихнуть update-ами в базу. И даже DataContext там может пригодиться.
Причем функция process :: Customer -> Customer никакими автомагическими путями в SQL не преобразуется, да и невозможно это в общем случае.

J>>Просто у меня мозг работает ближе к практике.

VD>В чем это заключается?

В том, что я пытаюсь идеи с "чистой" моделью работы с базой мысленно применить к тем задачам, с которыми я часто встречаюсь, и я не вижу каких-то повсеместных плюсов в этом подходе. Где-то "чистая" модель была бы к месту, особенно в простых сценариях типа "добавить запись в журнал" или что-то типа того. А где-то — подход Linq подошел бы лучше.

J>>Я понимаю что вы хотите. Но мне непонятны детали. Давай поговорим про конкретику:

VD>ОК

J>>1. как должно выглядеть в коде то, о котором вы говорите? Возьмем, например, update. Видимо там должно быть выражение, которое поставить в where и какой-то набор выражений про то, что сделать со столбцами. При чем для каждого выражения для каждого столбца должен быть доступ к контексту всей строки. Приведи хоть примерчик в псевдокоде.

VD>Если снова возникает вопрос, а как защититься от случайного переписывания данных, то это можно сделать так:
VD>

VD>var cutomer1 = ...;
VD>var oldName = cutomer1.SelectedData_Name; // данные когда-то полученные с сервера для свойства Name
VD>update set c.Name = "Новое имя" set c.Bonus = c.Bonus + 1; 
VD>   from c in customers 
VD>   where c is cutomer1
VD>     and c.Name == oldName; // старое 
VD>

Ну ок. Такое было бы иногда полезно. Чаще всего было бы полезно в плане проапдейтить часть полей в строке.

J>>Как это все будет выглядеть? Отдельно будут объекты с полями a, b и c, полученые из базы и отдельно — объекты с d и e для сохранения, так?

VD>Да. Первым запросом мы выберем нужные данные "from x in xs select a, b, c...". Затем обработаем их и запишем назад с помощью update.

Т.е. будет класс A{a,b,c} и класс B{d, e}. Может быть это и правильно концептуально, но не жирновато ли? А если потом еще C{b,c,d,e} и F{a,d,e} потребуются?

J>>Анонимные типы нельзя передавать между методами, поэтому про них забываем. Получается что для каждой нужной комбинации полей строки придется создавать свой объект?

VD>Если надо обработать только b и d, то и передай своей функции их. Ты же сам сказал, что обработка возможна только в потребительском коде.

Если их два, то может и ок. Но даже два параметра таскать между функциями — геморно.
Я бы лучше воспользовался отмэпленым объектом. Пусть там лишние поля будут, хрен с ними.

VD>Мне проблемы анонимных типов вообще фиолетовы. Я в основном пишу на Немерле, а там есть кортежи которые проблем с передачей между функциями не имеют.

А если нужно будет еще один параметр добавить? И хорошо бы — в середину кортежа, для красоты