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

J>Знаком с Haskell.

Видимо не очень глубоко.

J>Я не вижу прямой связи между ФП и тем, о чем мы сейчас говорим.

Линк был разработан одним из создателей Хакеля и в линке были применены подходы ДСЛ-естроенпия
опробированные в хаскеле.

J>В функциональном языке тоже можно вынуть список Customer-оа, переработать его в другой список Customer-ов и потом запихнуть update-ами в базу. И даже DataContext там может пригодиться.

Так и делали в HaskellDB. Только DataContext там не было.

J>Причем функция process :: Customer -> Customer никакими автомагическими путями в SQL не преобразуется, да и невозможно это в общем случае.

Гы-гы. Ошибаешься.
Курим http://haskelldb.sourceforge.net/

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

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

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

Это следствие твоего видения. Только и всего.
К тому же о какой-то пуританской чистоте никто и не говорит.

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

Ну, вот видишь?
Никто не говорит, что ты должен все делать только голым DML встроенным в язык. Но ведь и запись измененных объектов можно сделать на базе DML. Не правда ли?

А вот идентити трекинг как раз противоречит этому подходу.

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

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

Не обязательно класс. Это могут быть и отдельные объекты (или примитивные данные).
Но еще раз повторюсь, я бы предпочел добавить функцию в СУБД.

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

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

Ну, будет гемерно заведешь объект под эти цели. В конце концов это уже проблема не linq-dml, а C#-а. Не находишь?

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

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

А кортежам по фигу. Они и вложенными могут быть, и расширять их очень легко, и описать их тип не проблема (перечисляешь через * другие типы и все, например "int * strong * Customer").