Здравствуйте, 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").