Здравствуйте, gandjustas, Вы писали:
G>>>В вашем случае гораздо проще написать метод, генерирующий нужный SQL код по Query Expression.
L>>Это разве проще?!! Это ж процентов 80 Linq2SQL-а. G>а)это проще чем писать аналогичный фреймворк с нуля
Про какой фреймворк речь — про linq2sql или про тот, что будет по expression tree генерить соответствующий sql
G>б)это проще, чем переписывать все приложение на SQL
Гм. А кто-то предлагал переписать все на sql? Да и не факт что переписать на sql будет сложнее, зависит от размера приложения.
G>в)если нужен простой случай выборки в delete (без подзапросов), то это действительно просто
Посмотри вверх по ветке, с чего началалась речь про delete. Там как раз речь шла про подзапрос, да еще и с агрегатами.
Здравствуйте, MxKazan, Вы писали:
IT>>1. Типизацию работы с данными БД. MK>Ну в этом Linq далеко не первый.
В некотором смысле первый. Дело в том, что преобразованием имени класса в имя поля теперь занимается сам компилятор. Ранее это был ручной или генерируемый код.
MK> При этом в нём и гемора хватает, см. про удаление
. Мне также, например, не понравилось отсутствие того, что в ADO Entity Framework называют концептуальным слоем. Насколько я понимаю, Linq-to-Sql настраивается на модель БД при помощи атрибутов, следовательно, например, при изменении имени поля, мне приходится заниматься перегенерацией классов и перекопиляцией.
А что по-твоему есть типизация?
MK>Я уже и молчу про то, что куча настроек теряется при перегенерации (например, касательно участия поля в update'ах)
С какой стати?
IT>>2. linq 2 objects принципиально изменил способы обработки данных в памяти. MK>Так. Я видимо не в теме. А что принципиального нового linq 2 objects внёс по части "способы обработки данных в памяти"?
Linq 2 Objects внёс декларативность. Т.е. теперь я пишу что я хочу получить, а не как. В результате вместо кучи циклов с перебором списков и словарей у меня декларативная конструкция.
IT>>3. Возможность работать в функциональном стиле с человеческим лицом. MK>Честно говоря, никогда не страдал от отсутствия подобного в C#
Ты и не будешь страдать. Ты же не страдаешь из-за того, что не можешь видеть в инфракрасном диапазоне. Ты этого не умеешь, обходишься без такого умения и не страдаешь. Так же и здесь.
Неясность изложения обычно происходит от путаницы в мыслях.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, Хэлкар, Вы писали:
Х>Этюды nikov'a — это все же очень глубококопание — 90% разработчиков не знает ответов на большинство из них и живет себе припеваючи. В спек заглядывать не обязательно — программировать вполне можно прочитав например Троелсена (так сказать спек в разжеванном виде).
Во-первых, не издевайтесь над Трёльсеном (не знаю, хорошо ли он пишет, но всё равно нечего перевирать имя).
Во-вторых, все известные мне языки, которые пытались устранить низкоуровневые «сложности» и объединить сущности «объект» и «адрес объекта», наступили на одни и те же грабли и связывают объекты вместо копирования или наоборот неочевидным для программиста образом. Чем больше будет распространен C#, тем больше анонимов будут задавать одни и те же вопросы на соответствующих форумах. Да что далеко ходить: самое верхнее сообщение на rsdn.dotnet под модным номером 3110110
: «А теперь вопрос — почему при удалении строк из dt также удаляются строки из ViewState? Догадываюсь, что копируется ссылка, а как правильно скопировать, чтобы создалась копия объекта?». Тем более, что грабли замедленного действия: программа компилируется и работает, но тихо редактирует не те данные.
В-третьих, пока C# привязан к одной определенной платформе, он годится только на то, чтобы флудить о нем в ФП, а на сервер пойдут решения, которые при нужде можно будет перенести куда понадобится :-)
Здравствуйте, WolfHound, Вы писали:
WH>>>Не о том речь. Почитай правила поиска имен :maniac: стандарт писали садомазохисты. КЛ>>ничего особенного WH>Это ADL то ничего особенного?
ADL как раз не особенно сложен, а с концепциями C++09 его сделают вообще простым и красивым.
Проблемы вызывает двухфазный поиск имен, что еще и осложняется традиционной неподдержкой его компиляторами, которые мы не станем здесь называть, наподобие MSVC. Частый вопрос в rsdn.cpp: «почему class A<T>: X<T> { A() { f(); } } не работает, а this->f() работает?».
Здравствуйте, Roman Odaisky, Вы писали:
RO>Во-первых, не издевайтесь над Трёльсеном (не знаю, хорошо ли он пишет, но всё равно нечего перевирать имя).
Эндрю Троелсен (Andrew Troelsen) — стандартная трнскрипция. Откуда ваш вариант?
RO>Во-вторых, все известные мне языки, которые пытались устранить низкоуровневые «сложности» и объединить сущности «объект» и «адрес объекта», наступили на одни и те же грабли и связывают объекты вместо копирования или наоборот неочевидным для программиста образом. Чем больше будет распространен C#, тем больше анонимов будут задавать одни и те же вопросы на соответствующих форумах. Да что далеко ходить: самое верхнее сообщение на rsdn.dotnet под модным номером 3110110
: «А теперь вопрос — почему при удалении строк из dt также удаляются строки из ViewState? Догадываюсь, что копируется ссылка, а как правильно скопировать, чтобы создалась копия объекта?». Тем более, что грабли замедленного действия: программа компилируется и работает, но тихо редактирует не те данные.
RO>В-третьих, пока C# привязан к одной определенной платформе, он годится только на то, чтобы флудить о нем в ФП, а на сервер пойдут решения, которые при нужде можно будет перенести куда понадобится
Здравствуйте, IT, Вы писали:
IT>Здравствуйте, MxKazan, Вы писали:
IT>>>1. Типизацию работы с данными БД. MK>>Ну в этом Linq далеко не первый.
IT>В некотором смысле первый. Дело в том, что преобразованием имени класса в имя поля теперь занимается сам компилятор. Ранее это был ручной или генерируемый код.
А какая в сущности разница?
MK>> При этом в нём и гемора хватает, см. про удаление
. Мне также, например, не понравилось отсутствие того, что в ADO Entity Framework называют концептуальным слоем. Насколько я понимаю, Linq-to-Sql настраивается на модель БД при помощи атрибутов, следовательно, например, при изменении имени поля, мне приходится заниматься перегенерацией классов и перекопиляцией.
IT>А что по-твоему есть типизация?
Намёк ясен. Но он не совсем применим к Linq-To-Sql, уж слишком специфично, я написал чего не хватает. Видно и Microsoft это понимает, потому и есть Entity Framework. А проблема с DELETE похоже не имеет простого решения.
MK>>Я уже и молчу про то, что куча настроек теряется при перегенерации (например, касательно участия поля в update'ах)
IT>С какой стати?
Ну вот, например, мне хотелось обновлять объекты в БД так, чтобы генерируемый Sql запрос не проверял изменение остальных полей (имеется ввиду concurrency). Приходилось ручками проставлять почти всем полям класса UpdateCheck в Never. Поменял поле, перегенерил класс и опять давай проставлять. Справедливости ради скажу, это скорее следует отнести к недостаткам Студии.
IT>>>2. linq 2 objects принципиально изменил способы обработки данных в памяти. MK>>Так. Я видимо не в теме. А что принципиального нового linq 2 objects внёс по части "способы обработки данных в памяти"?
IT>Linq 2 Objects внёс декларативность. Т.е. теперь я пишу что я хочу получить, а не как. В результате вместо кучи циклов с перебором списков и словарей у меня декларативная конструкция.
Это понятно, про ФП я читал. Но не очень понятно в чем конкретная новизна по памяти? Речь о локальности данных? Но вообще, IT, я бы хотел еще раз обозначить, что я принципе не против Linq. Хотелось бы просто понимать реальную необходимость этого, реальные плюсы, а не просто как "игрушка для этюдов". Разве это есть гуд, требовать "что", не понимая "как"?
Здравствуйте, MxKazan, Вы писали:
MK>Ну вот, например, мне хотелось обновлять объекты в БД так, чтобы генерируемый Sql запрос не проверял изменение остальных полей (имеется ввиду concurrency). Приходилось ручками проставлять почти всем полям класса UpdateCheck в Never. Поменял поле, перегенерил класс и опять давай проставлять. Справедливости ради скажу, это скорее следует отнести к недостаткам Студии.
Не совсем понятно, что ты имеешь в виду под "перегенерил класс".
Класс генерится при любом изменении в dbml-е (при сохранении), но тогда получается, что update check поменять пообще невозможно, ведь после изменеиния update check-а класс снова будет перегенерен и его снова нужно будет выставлять.
Здравствуйте, Lloyd, Вы писали:
L>Здравствуйте, MxKazan, Вы писали:
MK>>Ну вот, например, мне хотелось обновлять объекты в БД так, чтобы генерируемый Sql запрос не проверял изменение остальных полей (имеется ввиду concurrency). Приходилось ручками проставлять почти всем полям класса UpdateCheck в Never. Поменял поле, перегенерил класс и опять давай проставлять. Справедливости ради скажу, это скорее следует отнести к недостаткам Студии.
L>Не совсем понятно, что ты имеешь в виду под "перегенерил класс". L>Класс генерится при любом изменении в dbml-е (при сохранении), но тогда получается, что update check поменять пообще невозможно, ведь после изменеиния update check-а класс снова будет перегенерен и его снова нужно будет выставлять.
Ыыыы... Это я имел ввиду, генерацию класса дизайнером, когда взял ручками и перетащил из Server Explorer'а
Это всё уже реализация, это можно изъять из обсуждения.
Здравствуйте, MxKazan, Вы писали:
L>>Класс генерится при любом изменении в dbml-е (при сохранении), но тогда получается, что update check поменять пообще невозможно, ведь после изменеиния update check-а класс снова будет перегенерен и его снова нужно будет выставлять. MK>Ыыыы... Это я имел ввиду, генерацию класса дизайнером, когда взял ручками и перетащил из Server Explorer'а MK>Это всё уже реализация, это можно изъять из обсуждения.
А нефик тащить из сервер-эксплорера, он для добавления новых объектов. Хочешь обновлять — обновляй руками.
Здравствуйте, eao197, Вы писали:
E>Здравствуйте, MxKazan, Вы писали:
G>>>ЗЫ. Я подобное мнение видел у прожженых C++ников, которые впоследствие перешли на C#. MK>>Можно расслабиться и спокойно общаться. Мой профессиональный опыт — 3 года сплошного C#. Никакого C++.
E>Вот и выросло новое поколение
Отсутствие продакшн-опыта на нативном языке не означает непонимание основных принципов и неумение программировать на нём. До этого было гораздо больше времени, проведённого с Делфи, где и указатели пройдены и WinApi поюзано немало и много еще чего. И на C# общение, например, с MAPI бывало, с маршалиногом managed в unmanaged. Такое вот оно новое поколение, не стесняется
Здравствуйте, Lloyd, Вы писали:
L>Здравствуйте, MxKazan, Вы писали:
L>>>Класс генерится при любом изменении в dbml-е (при сохранении), но тогда получается, что update check поменять пообще невозможно, ведь после изменеиния update check-а класс снова будет перегенерен и его снова нужно будет выставлять. MK>>Ыыыы... Это я имел ввиду, генерацию класса дизайнером, когда взял ручками и перетащил из Server Explorer'а MK>>Это всё уже реализация, это можно изъять из обсуждения.
L>А нефик тащить из сервер-эксплорера, он для добавления новых объектов. Хочешь обновлять — обновляй руками.
Дык он там генерит массу всего! Боюсь, что поправив ручками, что нибудь да пропущу
Здравствуйте, MxKazan, Вы писали:
L>>А нефик тащить из сервер-эксплорера, он для добавления новых объектов. Хочешь обновлять — обновляй руками.
MK>Дык он там генерит массу всего! Боюсь, что поправив ручками, что нибудь да пропущу
Под обновлять ручками я имел в виду, не изменение исходников, которые генерит кастом тул, а изменение объектов в диаграме, там настроек уже не так много.
Здравствуйте, Lloyd, Вы писали:
L>Посмотри вверх по ветке, с чего началалась речь про delete. Там как раз речь шла про подзапрос, да еще и с агрегатами.
А можно ли использовать все возможности запросов в операторе delete?
Я c TSQL плохо знаком, по стандарту SQL-92 возможности фильтрации в delete сильно ограничены.
Может оказаться что на уровне генерации sql по Expression такая проблема не решается вообще.
Здравствуйте, gandjustas, Вы писали: G>А можно ли использовать все возможности запросов в операторе delete?
Да. Всю мощь SQL. G>Я c TSQL плохо знаком, по стандарту SQL-92 возможности фильтрации в delete сильно ограничены.
G>Может оказаться что на уровне генерации sql по Expression такая проблема не решается вообще.
Очевидно, решается. Если можно сделать select, то можно и delete.
Аналогичная задача возникает у нас и при попытке воспользоваться insert into ... select ().
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, gandjustas, Вы писали: G>>А можно ли использовать все возможности запросов в операторе delete? S>Да. Всю мощь SQL.
Да уж, надо изучать T-SQL.
G>>Может оказаться что на уровне генерации sql по Expression такая проблема не решается вообще. S>Очевидно, решается. Если можно сделать select, то можно и delete. S>Аналогичная задача возникает у нас и при попытке воспользоваться insert into ... select ().
А еще update есть...
Здравствуйте, gandjustas, Вы писали:
L>>Посмотри вверх по ветке, с чего началалась речь про delete. Там как раз речь шла про подзапрос, да еще и с агрегатами. G>А можно ли использовать все возможности запросов в операторе delete? G>Я c TSQL плохо знаком, по стандарту SQL-92 возможности фильтрации в delete сильно ограничены.
Да особо сложных возможностей и не надо. Достаточно
DELETE FROM tbl WHERE pk IN (тут-любой-запрос)
G>Может оказаться что на уровне генерации sql по Expression такая проблема не решается вообще.
Это еще почему? По моему вполне решается, только вот сложность решения = равна сложности генерации select-оа по expression-ам = ~80%-ов Linq2Sql-я.
Здравствуйте, Хэлкар, Вы писали:
RO>>Во-первых, не издевайтесь над Трёльсеном (не знаю, хорошо ли он пишет, но всё равно нечего перевирать имя). Х>Эндрю Троелсен (Andrew Troelsen) — стандартная трнскрипция.
Ну да, а автора «Фауста» зовут Гоетхе.
Фамилия у него, насколько я понимаю, датского происхождения (Trølsen). Так его сначала и переводили, а потом, когда он стал писать на тему новомодного .NET, издательства бросились в спешке переводить и не осилили даже фамилию. Их же (переводчиков) мы должны благодарить за «перегруженные функции», «.NET программирование» и т. п.
Как бы то ни было, «Troelsen» ни при каких обстоятельствах не произносится ни как «Тройелсен», ни как «Троэлсен». Ты же сам употребил слово «транскрипция», хотя «Троелсен» — это транслитерация, а не транскрипция. Почему «Эндрю», а не «Андрев»?
Если нам не помогут, то мы тоже никого не пощадим.
