Здравствуйте, Aen Sidhe, Вы писали:
AS>А можно где-нибудь посмотреть на пример такого фреймворка? Или почитать?
Если говорить о типзированном решение встроенном в ООЯ, то таких я не видел пока. Мы как раз и говорим, что хорошо было бы линк доработать напильником до этого состояния.
А если же говорить о похожих вещах, то наверно, как не странно ближе всего к этому подходу будут сами СУБД и подход с использованием датасетов (ADO.NET) или отсоедененных рекордсетов (ADO КОМовское, не нет которое).
AS>Ну, тут есть другие люди, они читают. Я вот пока не до конца понял, как это будет работать
Ну, так в корневом сообщении темы вроде как все разъяснено. Что конкретно не ясно?
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Jakobz, Вы писали:
J>Нет. Просто у меня мозг работает ближе к практике. Я понимаю что вы хотите. Но мне непонятны детали. Давай поговорим про конкретику: J>1. как должно выглядеть в коде то, о котором вы говорите? Возьмем, например, update. Видимо там должно быть выражение, которое поставить в where и какой-то набор выражений про то, что сделать со столбцами. При чем для каждого выражения для каждого столбца должен быть доступ к контексту всей строки. Приведи хоть примерчик в псевдокоде. И как быть с update из другого select-а?
Какой синтаксис пожно придумать я не знаю, но вполне можно описать методы.
Update<T>(Expression<Func<T,T>>,IQueryable<T>)
Первый параметр соотвественно описывает преобразование строк, второй — выборку для которой выполняется преобразование (фактически из нее только предложение where берется).
Insert<T>(Table<T>, IQueryable<T>)
Delete<T>(IQueryable<T>)
Это еще проще.
J>2. очевидно что программу из одних select-ов и update-ов не напишешь. Между ними данные должны попадать в код и как-то обрабатываться. Например у нас есть три колонки a, b и c. Нам нужно сделать какие-то вычисления и положить результат в колонки d и e. Предположим что для этого задействуется большое количество C#-кода. И что переписать это в форме запроса в базу нельзя — например d и e запрашиваются у стороннего веб-сервиса. J>Как это все будет выглядеть? Отдельно будут объекты с полями a, b и c, полученые из базы и отдельно — объекты с d и e для сохранения, так? Анонимные типы нельзя передавать между методами, поэтому про них забываем. Получается что для каждой нужной комбинации полей строки придется создавать свой объект?
Такое никак не решается, надо явно городить транзакцию.
Но гораздо лучше поменять логику приложения чтобы вставка осуществлялась так, чтобы было a,b,c,d,e вместе.
Вообще говоря работа с данными с помощью только DML приводит к другому построению логики.
То есть у вас не возникнет многих проблем, о которым вы сейчас можете написать.
J>3. как быть, если в update что-то сложнее, чем встроеные в sql функции? Что должен сделать LINQ, если он не может выполнить на БД какой-нибудь гиперболический косинус? Тащить все в код, там перефигачивать и заливать назад?
Не надо тащить все в код приложения, лучше засунуть SQL CLR функции на сервер.
Вот то что я себе сейчас с трудом представляю как делать в DML: сомещение операций добавления и апдейта.
Например на форме мы добавляем, меняем или удаляем какие-то пункты списка. Потом нам все изменения надо записать в базу при нажатии кнопки "сохранить".
В таком случае мне кажется то UoW будет решать, поэтому совсем отказываться от него не стоит.
но уж точно он не будет основным способом работы с данными.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, Aen Sidhe, Вы писали:
AS>>А можно где-нибудь посмотреть на пример такого фреймворка? Или почитать?
VD>А если же говорить о похожих вещах, то наверно, как не странно ближе всего к этому подходу будут сами СУБД и подход с использованием датасетов (ADO.NET) или отсоедененных рекордсетов (ADO КОМовское, не нет которое).
Хм. Ну, т.е. обычные списки данных. Понятно.
AS>>Ну, тут есть другие люди, они читают. Я вот пока не до конца понял, как это будет работать
VD>Ну, так в корневом сообщении темы вроде как все разъяснено. Что конкретно не ясно?
Я имел ввиду — как работать с БД без DataContext'ов? Код, который будет заниматься сохранением данных в РСУБД будет где? И как он будет работать? Я либо туплю, либо просто не знаю, но мне на ум только ActiveRecord приходит.
Здравствуйте, Jakobz, Вы писали:
J>Я не тебе отвечал вообще-то и тебя не задалбывал.
Ты Маугли кого хочешь достанешь (с) анекдот.
Тебе тут все на разный лад простейшую мысль пытаются донести. И все без толку.
J>Задаете вопрос зачем identity tracking, я отвечаю.
Ну, и что ты отвечаешь то? Сам почитай...
Identity tracking нужен для модели с датаконтекстом. А зачем нужна эта модель и все ее прибамбасы?
Сто лет назад придумали SQL который оптимален для манипуляции данными с БД.
Таз зачем нужна модель которая пытается спрятать от нас то, что данные лежат в БД?
J>Записывать можно и без контекста и без трекинга. А можно — с контекстом и трекингом.
А зачем с ними то?
VD>>У тебя мозг уже работает только в условиях одной парадигмы. Объяснить тебе что-то невозможно, так как ты просто не хочешь воспринять наличие другой парадигмы.
J>Нет.
Уверяю тебя. Ты знаком хотя бы с одним функциональным языком? Чувствую, что нет.
Так вот попробуй изучить. Уверяю тебя, что крышу будет рвать не по детски. А меж тем ничего сложного там нет. Просто несоответствие межд тем как ты видишь мир вычислений и тем как ее представляет модель ФП.
Вот та же байда и здесь.
J>Просто у меня мозг работает ближе к практике.
В чем это заключается?
J>Я понимаю что вы хотите. Но мне непонятны детали. Давай поговорим про конкретику:
ОК
J>1. как должно выглядеть в коде то, о котором вы говорите? Возьмем, например, update. Видимо там должно быть выражение, которое поставить в where и какой-то набор выражений про то, что сделать со столбцами. При чем для каждого выражения для каждого столбца должен быть доступ к контексту всей строки. Приведи хоть примерчик в псевдокоде.
Мне прийдется тебе просто привести пример SQL-ного update-а.
Ну, скажем:
update set c.Name = "Новое имя" from c in customers where c.id = 123;
или
var cutomer1 = ...;
update set c.Name = "Новое имя" set c.Bonus = c.Bonus + 1;
from c in customers
where c is cutomer1;
что тоже самое, но id будет взят не явно из экземпляра cutomer1 в котором он хранится.
Для таких примитивных случав конечно можно использовать и изменение объекта с последующей передачей его в метод который выявит изменения и преобразует их в вызов update.
Если снова возникает вопрос, а как защититься от случайного переписывания данных, то это можно сделать так:
var cutomer1 = ...;
var oldName = cutomer1.SelectedData_Name; // данные когда-то полученные с сервера для свойства Name
update set c.Name = "Новое имя" set c.Bonus = c.Bonus + 1;
from c in customers
where c is cutomer1
and c.Name == oldName; // старое
J>И как быть с update из другого select-а?
Точно так же:
var cutomer1 = ...;
var oldName = cutomer1.SelectedData_Name; // данные когда-то полученные с сервера для свойства Name
update set c.Bonus = c.Bonus + 1;
from c in customers
where (from o in orders where c.Total > 1000m select o.CustomerId)
.Distinct().Contains(c.id)
J>2. очевидно что программу из одних select-ов и update-ов не напишешь.
Э... не очевидно конечно. Но наверно смысла в этом нет.
J>Между ними данные должны попадать в код и как-то обрабатываться. Например у нас есть три колонки a, b и c. Нам нужно сделать какие-то вычисления и положить результат в колонки d и e. Предположим что для этого задействуется большое количество C#-кода. И что переписать это в форме запроса в базу нельзя — например d и e запрашиваются у стороннего веб-сервиса.
Переписать это скорее всего будет можно. В конце концов нем никто не запрещает создать дотнетную функцию, описать ее как SQL-ую и вызвать ее в рамках одного запроса.
Но и вытащить данные для обработки не проблема.
J>Как это все будет выглядеть? Отдельно будут объекты с полями a, b и c, полученые из базы и отдельно — объекты с d и e для сохранения, так?
Да. Первым запросом мы выберем нужные данные "from x in xs select a, b, c...". Затем обработаем их и запишем назад с помощью update.
J>Анонимные типы нельзя передавать между методами, поэтому про них забываем. Получается что для каждой нужной комбинации полей строки придется создавать свой объект?
Если надо обработать только b и d, то и передай своей функции их. Ты же сам сказал, что обработка возможна только в потребительском коде.
Мне проблемы анонимных типов вообще фиолетовы. Я в основном пишу на Немерле, а там есть кортежи которые проблем с передачей между функциями не имеют.
J>3. как быть, если в update что-то сложнее, чем встроеные в sql функции? Что должен сделать LINQ, если он не может выполнить на БД какой-нибудь гиперболический косинус? Тащить все в код, там перефигачивать и заливать назад?
Я бы создавал внешние функции и использовал бы их на сервере.
ЗЫ
Не знаю умеют ли сегодняшние Linq2SQL и EF работать с внешними функциями, но если даже не умеют, то следовал бы их этому научить.
У нас тут IT пишет свой LINQ-провайдер. Думаю, в нем мы реализуем все необходимое. А в Немерле прикрутим синтаксис. Шарп будет довольствоваться кодом без синтаксиса (с явной передачей лямбд в ФВП).
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
AS>Я имел ввиду — как работать с БД без DataContext'ов? Код, который будет заниматься сохранением данных в РСУБД будет где? И как он будет работать? Я либо туплю, либо просто не знаю, но мне на ум только ActiveRecord приходит.
Ну обычный DML работает через Connection и ниче.
В принципе для более сложной системы DataContext будет чуть более сложной версией коннекшена.
Сейчас же объекты контекстов сочетают в себе еще и identity\change tracking, средства ленивой и отложенной загрузки, а также управление всем этим барахлом.
Здравствуйте, gandjustas, Вы писали:
G>Здравствуйте, Aen Sidhe, Вы писали:
AS>>Я имел ввиду — как работать с БД без DataContext'ов? Код, который будет заниматься сохранением данных в РСУБД будет где? И как он будет работать? Я либо туплю, либо просто не знаю, но мне на ум только ActiveRecord приходит. G>Ну обычный DML работает через Connection и ниче. G>В принципе для более сложной системы DataContext будет чуть более сложной версией коннекшена.
А, вон оно в чём дело.
G>Сейчас же объекты контекстов сочетают в себе еще и identity\change tracking, средства ленивой и отложенной загрузки, а также управление всем этим барахлом.
Меня эта ленивая загрузка, всовываемая написателями ОРМ налево и направо уже изрядно достала.
Здравствуйте, Aen Sidhe, Вы писали:
AS>Я имел ввиду — как работать с БД без DataContext'ов? Код, который будет заниматься сохранением данных в РСУБД будет где? И как он будет работать? Я либо туплю, либо просто не знаю, но мне на ум только ActiveRecord приходит.
А как раньше работали? SQL-я за глаза хватает. Раньше он в язык не вписывался, а теперь вписывается...
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, Aen Sidhe, Вы писали:
AS>>Я имел ввиду — как работать с БД без DataContext'ов? Код, который будет заниматься сохранением данных в РСУБД будет где? И как он будет работать? Я либо туплю, либо просто не знаю, но мне на ум только ActiveRecord приходит.
VD>А как раньше работали? SQL-я за глаза хватает. Раньше он в язык не вписывался, а теперь вписывается...
Здравствуйте, Aen Sidhe, Вы писали:
VD>>А как раньше работали? SQL-я за глаза хватает. Раньше он в язык не вписывался, а теперь вписывается...
AS>Раньше люди топорами брились. Не удобно.
В том то все и дело, что (если уж прибегать к аналогиям) топор — это датаконтексты с трекингом, так как эта идеология подразумевает обработку отдельных деревьев (объектов). А SQL — это как раз станок с ЧПУ и автоматической подачей тех самых бревен. В нем можно за раз целый лес обработать.
Потому мне никогда и не было понятно, зачем люди так даунгрэйтнулись — перешли от декларативных запросов к возней с отдельными объектами.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, Aen Sidhe, Вы писали:
VD>>>А как раньше работали? SQL-я за глаза хватает. Раньше он в язык не вписывался, а теперь вписывается...
AS>>Раньше люди топорами брились. Не удобно.
VD>В том то все и дело, что (если уж прибегать к аналогиям) топор — это датаконтексты с трекингом, так как эта идеология подразумевает обработку отдельных деревьев (объектов). А SQL — это как раз станок с ЧПУ и автоматической подачей тех самых бревен. В нем можно за раз целый лес обработать.
Зачастую мне надо сделать из одного бревна пару стульев и столешницу (работа с одной сущностью "документ"). Станок мне не нужен. В другом случае мне надо работать с лесом ("data mining") — вот тут уже можно и нужно юзать станки с ЧПУ.
VD>Потому мне никогда и не было понятно, зачем люди так даунгрэйтнулись — перешли от декларативных запросов к возней с отдельными объектами.
Чистый SQL минимум в половине случаев не удобен. Я думаю, я не буду повторяться про отсутствие compile-time проверок и т.д. Основная проблема для меня лично сейчас состоит в том, что для написания простой тулзы мне надо либо возиться с SQL и по сто раз лепить CRUD-операции, либо танцевать вокруг DataContext'ов. Второй вариант пока проще.
Здравствуйте, Aen Sidhe, Вы писали:
AS>Зачастую мне надо сделать из одного бревна пару стульев и столешницу (работа с одной сущностью "документ"). Станок мне не нужен. В другом случае мне надо работать с лесом ("data mining") — вот тут уже можно и нужно юзать станки с ЧПУ.
Вообще-то в современном мире стулья и столы делают как раз на станках. Но эти аналогии уже как-то очень далеко ушли от темы.
VD>>Потому мне никогда и не было понятно, зачем люди так даунгрэйтнулись — перешли от декларативных запросов к возней с отдельными объектами.
AS>Чистый SQL минимум в половине случаев не удобен.
Это придумали люди которые его не понимали.
AS> Я думаю, я не буду повторяться про отсутствие compile-time проверок и т.д.
Дык это не проблемы SQL-я. SQL вполне себе статически типизированный язык...
AS>Основная проблема для меня лично сейчас состоит в том, что для написания простой тулзы мне надо либо возиться с SQL и по сто раз лепить CRUD-операции, либо танцевать вокруг DataContext'ов. Второй вариант пока проще.
В просто не умеете его готовить (с) реклама.
Точнее просто SQL пока что не завернут в используемый тобой язык так как нужно. Точнее линк как раз завертывает его в язык, но только на половину. И мы как раз ведем речь о том, чтобы довести начатое до конца и завернуть его полностью.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
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>Мне проблемы анонимных типов вообще фиолетовы. Я в основном пишу на Немерле, а там есть кортежи которые проблем с передачей между функциями не имеют.
А если нужно будет еще один параметр добавить? И хорошо бы — в середину кортежа, для красоты
J>Я не вижу прямой связи между ФП и тем, о чем мы сейчас говорим. В функциональном языке тоже можно вынуть список Customer-оа, переработать его в другой список Customer-ов и потом запихнуть update-ами в базу. И даже DataContext там может пригодиться.
Еще раз. Пока вы не откажетесь от способа работы "вынуть, обработать, положить" ничего хорошего не выйдет.
J>Причем функция process :: Customer -> Customer никакими автомагическими путями в SQL не преобразуется, да и невозможно это в общем случае.
В общем случае не возможно, а во многих частных очень даже. В Linq ведь работает.
Здравствуйте, 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").
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
J>>Причем функция process :: Customer -> Customer никакими автомагическими путями в SQL не преобразуется, да и невозможно это в общем случае.
VD>Гы-гы. Ошибаешься. VD>Курим http://haskelldb.sourceforge.net/
restr =
withDB $ \db ->
do rows <- query db $
do result <- table P.farmers
restrict (result!P.farm_id .==. constant 0)
return result
mapM_ (putStrLn .showP) rows
и где тут автомагические преобразования? Строят как и в Linq модель выражения и по ней лепят Sql. Никакой магии.
VD>Ну, вот видишь? VD>Никто не говорит, что ты должен все делать только голым DML встроенным в язык. Но ведь и запись измененных объектов можно сделать на базе DML. Не правда ли?
Можно, я и не спорил. Я просто говорил что это может быть удобнее.
Здравствуйте, Jakobz, Вы писали:
J>и где тут автомагические преобразования? Строят как и в Linq модель выражения и по ней лепят Sql. Никакой магии.
А ты хотел чуда?
Это наука, а не оккультные науки.
Это и есть прототип линка. Только Хаскелю не потребовалось вводить в язык новые сущности, чтобы можно было эту поддержку реализовать.
VD>>Ну, вот видишь? VD>>Никто не говорит, что ты должен все делать только голым DML встроенным в язык. Но ведь и запись измененных объектов можно сделать на базе DML. Не правда ли?
J>Можно, я и не спорил. Я просто говорил что это может быть удобнее.
Что?
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Tissot, Вы писали:
T> ...
Я сразу извиняюсь, что а) отвечаю вам, потому б) что возможно кого-то повторю, ибо до конца не дочитал, не вытерпел
Итак, основной спор помниться был о массовых апдейтах, и почему в ЛИНК нет синтаксиса для "массовых апдейтов", и почему скрипт транзакции лучше, чем UoW.
Я полностью согласен с поклонниками скриптов транзакций, но они забывают (забывали, по крайней мере, на первой странице) одну простую вещь: для того, чтобы скрипт транзакций отработал, все объекты из контекста нужно сохранить в базу данных.
Никакая база данных и никакой линк не сможет сформировать текст апдейт запроса так, чтобы база данных подхватила изменения локальных объектов. А это значит, что Апдейт в ЛИНКЕ
мог бы выглядеть в нескольких вариантах:
а) Типизированное выражение
update c in collection set new { Id = c.Id, Name = c.ItemName} where c.Id == 12
, которое преобразуется в апдейт с параметрами, параметры вычисляются по контексту, и апдейт выполняется на сервере. После этого весь контекст, на котором была выполнена такая операция можно выкинуть, т.к. он уже неактуален. При этом все локальные изменения никоим образом в апдейте не участвуют, т.к. они еще не попали в базу. Зачем нужен такой апдейт — полностью непонятно.
б) Выражение, аналогичное предыдущему, но с неявным предварительным коммитом в базу.
б) Типизированное выражение, которое не работает с экземплярами объектов, что-то типа
Однако, проблема с невалидностью контекста после этого таки остается.
Далее, отказавшись от Unit of Work в линке мы для сохранения объектов вынуждены использовать такой же кастрированный апдейт. Причем, сохранять каждый объект отдельно и в цикле, сами отслеживая его изменения. Чем не единица работы своими руками?
Насколько я понимаю, в ЛИНК отказались от массовых операций обновления именно по причине того, что часть ЛИНК которая для SQL задумывалась именно для облегчения операций массовых неалгоритмических обновлений данных. То есть грубо говоря, показав пользователю список товаров для редактирования, вы не сможете составить апдейт запрос иначе как проапдейтив каждый элемент отдельно. А это и есть единица работы.
А ежели надо скрипт транзакций — так пожалуйста, хранимые процедуры именно для этой цели и существуют.
Здравствуйте, Sergey T., Вы писали:
ST>Никакая база данных и никакой линк не сможет сформировать текст апдейт запроса так, чтобы база данных подхватила изменения локальных объектов. А это значит, что Апдейт в ЛИНКЕ ST>мог бы выглядеть в нескольких вариантах: ST> а) Типизированное выражение ST>
ST>update c in collection set new { Id = c.Id, Name = c.ItemName} where c.Id == 12
ST>
ST>, которое преобразуется в апдейт с параметрами, параметры вычисляются по контексту, и апдейт выполняется на сервере. После этого весь контекст, на котором была выполнена такая операция можно выкинуть, т.к. он уже неактуален. При этом все локальные изменения никоим образом в апдейте не участвуют, т.к. они еще не попали в базу. Зачем нужен такой апдейт — полностью непонятно.
Непонятно, если есть контекст. Если же выкинуть контекст не после операции, а вообще, то всё становится понятно и логично.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, IT, Вы писали:
IT>Непонятно, если есть контекст. Если же выкинуть контекст не после операции, а вообще, то всё становится понятно и логично.
Добавлю, что тот что называется "юнит оф ворк" и так есть ни что иное как несколько изменений производимых в рамках одной транзакции.
Если потребуется реализовать паттерн записывающий изменения списка объектов, то не сложно будет сделать автоматический генератор update-запросов который сформирует эти запросы и выполнит их в рамках одной транзакции.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Sergey T., Вы писали:
ST>Здравствуйте, Tissot, Вы писали:
T>> ... ST>Я сразу извиняюсь, что а) отвечаю вам, потому б) что возможно кого-то повторю, ибо до конца не дочитал, не вытерпел
ST>Итак, основной спор помниться был о массовых апдейтах, и почему в ЛИНК нет синтаксиса для "массовых апдейтов", и почему скрипт транзакции лучше, чем UoW.
ST>Я полностью согласен с поклонниками скриптов транзакций, но они забывают (забывали, по крайней мере, на первой странице) одну простую вещь: для того, чтобы скрипт транзакций отработал, все объекты из контекста нужно сохранить в базу данных.
При таком подходе у нас просто не будет объектов в контексте. Вообще не будет.
ST>Далее, отказавшись от Unit of Work в линке мы для сохранения объектов вынуждены использовать такой же кастрированный апдейт. Причем, сохранять каждый объект отдельно и в цикле, сами отслеживая его изменения. Чем не единица работы своими руками?
Отслеживание изменений — необходимость при работе с объектами. Если отказываемся от UoW то у нас и логика будет по-другом строиться.
Нам в принципе не нужны будут циклы, вся массовая обработка будет заключаться именно в выполнении запроса.
А уже на основе этой системы можно реализовать и UoW, только зачем...
ST>Насколько я понимаю, в ЛИНК отказались от массовых операций обновления именно по причине того, что часть ЛИНК которая для SQL задумывалась именно для облегчения операций массовых неалгоритмических обновлений данных. То есть грубо говоря, показав пользователю список товаров для редактирования, вы не сможете составить апдейт запрос иначе как проапдейтив каждый элемент отдельно. А это и есть единица работы.
Для чего он задумывался вообще непонятно.
Вероятнее всего Linq2SQL был всего лишь proof of concept идеи с Expression Tree. О грамотной проработке его как ORM или как средства реляцонной работы с данными никто и не задумывался. Слизали несколько наиболее востребованных фич с существующих ORM и забили.
ST>А ежели надо скрипт транзакций — так пожалуйста, хранимые процедуры именно для этой цели и существуют.
Проблема по большей части в SQL, он не проверяется при компиляции приложения, у него мало средст для динамической генерации запросов и мало средств для борьбы со сложностью.
Если нам не помогут, то мы тоже никого не пощадим.
