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

[]

S>>>Так что linq получается офигенно удобным там, где он есть, безо всяких ws.
КЛ>>ну они не слабо связанные, тем более что asp.net pages и ws и есть то самое разделение
S>Разделение на что? ASP.NET не нуждается в WS. WS нужны исключительно для кроссплатформенного взаимодействия; тебе никто не запрещает сделать не tier, а layer — то есть разделить средний слой (ASP.NET сервер) на presentation layer и application layer, обращаясь из первого ко второму при помощи Linq. Физически всё при этом будет ездить в рамках одного процесса (домена).

ок, интересует архитектура вида pres. layer (asp.net) -> app layer (?) -> sql serv. Причем обмен м/у pres., app, sql через linq (все они физически разнесены). Похоже, что готового решения нет, да и нужно ли оно?

Здравствуйте, Константин Л., Вы писали:

КЛ>ок, интересует архитектура вида pres. layer (asp.net) -> app layer (?) -> sql serv. Причем обмен м/у pres., app, sql через linq (все они физически разнесены). Похоже, что готового решения нет,
Совершенно верно — нет.
КЛ>да и нужно ли оно?
Нужно, хоть и редко. На самом деле, я уверен, что как только появится удачная реализация, ее востребованность резко возрастет. А через пару лет вообще будет считаться, что без этого жить незачем

Вообще, вокруг да около этого копают достаточно много. Помимо упоминавшегося поста Игоря Сухова, я встречал еще давно и такой подход, когда берется некий готовый API (к примеру, RESTаful, или даже SOAP), и к нему делается Linq фронтенд.
Полезные ссылки есть вот здесь. К данному классу относятся:
— Linq to Amazon
— Linq to WebQueries
— Linq to Flickr
— Link to SharePoint

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

C>>На XPath не изобразить остальные операции, AFAIK.
S>Изобразить-изобразить.
Как например изобразить хотя бы cross join? (или ты xpath 2.0 имеешь в виду?)

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

S>Здравствуйте, Константин Л., Вы писали:

КЛ>>ок, интересует архитектура вида pres. layer (asp.net) -> app layer (?) -> sql serv. Причем обмен м/у pres., app, sql через linq (все они физически разнесены). Похоже, что готового решения нет,
S>Совершенно верно — нет.
Неправда, есть. ADO.NET Data Services зовется.

КЛ>>да и нужно ли оно?
S>Нужно, хоть и редко. На самом деле, я уверен, что как только появится удачная реализация, ее востребованность резко возрастет. А через пару лет вообще будет считаться, что без этого жить незачем
Реализация есть, посмотри как будет чуствовать себя к выходу четвертого фреймворка.

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

VD>Спорить с ним бесполезно, так как мы говорим, о том как Кибернэйм позиционируют его авторы, а он о том виртуальном Кибернейте который был создан его воображением путем ограничения возможностей и перенацеливания.

Что интересно, то же самое можно сказать про тебя и линк Ты игноригруешь ORM часть linq2sql и концентрируешься на запросах.

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


S>Весь смысл lazy loading — в том, чтобы спрятать от его пользователя информацию о том, когда именно происходит загрузка данных. Если программист видит, где именно происходит loading, то LL облажался. LL делает вид, что order.Items уже здесь и сейчас, а на самом деле они все еще в базе, и будут запрошены только когда я начну итерироваться по Items.

S>Ну так вот его leakyness состоит в том, что на самом деле есть существенная разница между "здесь и сейчас" и "всё еще в базе". Функционально разницы нет. А вот с точки зрения производительности — разница есть. И когда я буду делать вызов order.Items(i).StockItem.Name, он легко приведет к отдельному запросу на каждой итерации. И протечка будет ровно в том, что это приведет к чудовищной производительности данного решения. Это 100% аналог проблемы с конкатенацией строк, которую приводит Спольски.

S>И все способы борьбы с вот этой вот протечкой — это фактически отказ от абстракции. Вместо того, чтобы наивно итерироваться по order.Items, я буду должен отдать специальный cache hint и заставить ORM всё-таки залоадить данные энергичным способом. То есть никакого Lazy load уже нет, уже есть "forced lazy load". Всё, это и был щасливый конец LL.

S>Понимание причин протекания абстракции "persistence ignorance" оставляю в качестве домашнего задания.

Sinclair, в одном с вами и, наверное, IB, спорить трудно: нельзя, используя ОРМ, совсем "забывать" о данных. Нельзя полностью абстрагироваться от базы данных как хранилища со своей спецификой. Нельзя — как нельзя базу данных представить полностью в абстракции только наборов записей — без индексов, хинтов и тому подобных тонкостей. Потому что результат обеих абстракций будет один: работать будет, но очень часто медленно.


Приведенный вами пример, если представить его в абстракции СУБД, будет выглядеть примерно следующим образом

select * from 
order 
inner join orderItems on ...
inner join stockItems on ... 

where order.id = @someId

Следует заметить, что убери из базы все индексы и ключи — запрос этот будет ненамного быстрее работать, чем приведенный выше лейзи лоад.
То есть, база данных сама не может обладать достаточной информацией для построения оптимального по производительности хранилища. Ей нужна дополнительная информация.

Проведите эту аналогию на ОРМ — и вы увидите, что ОРМ тоже нуждается в такой же дополнительной информации. Например, указания о том, что весь ордер нужно грузить одним запросом — таким, какой приведен выше. Тогда разница на взаимодействие с СУБД сведется до нуля по сравнению с прямым запросом через IDataReader, и останутся лишь затраты на маппинг и т.п.

В чем же квинтэссенция современных субд? В том, что они дают для работы одну главную абстракцию — таблицу. И декларативный язык к ней. Все остальное — представления, индексы, хранимые процедуры — это средства ускорения работы (плюс модульности, повторного использования и т.п. — но сейчас не об этом). Причем стремится все к тому, чтобы об средствах ускорения работы забыть, как о минувшем веке (пока не получается). Суть же в том, чтобы отделить декларативный язык запросов от средства ускорения этих же запросов.

Аналогично и ОРМ — да, по состоянию "на сейчас" можно запросто произвести код, который положит производительность на лопатки. Но суть то не в этом — суть в том, что ОРМ стремится к идеалу, той самой пресловутой persistence ignorance. Как и СУБД стремится к INDEX IGNORANCE, HINTS IGNORANCE и т.п.

Пока же мы видим, что СУБД подходят очень интеллектуально к вопросам производительности. ОРМ — подходят к вопросам производительности "заблаговременно" и жестко — то есть, можно указать, что ордер нужно грузить таким вот одним запросом с товарами и строками вместе. Потому что они чаще всего вместе используются.

Но уважаемые — цель ОРМ — это не дать замену СУБД. Это дать возможность работать в смешанном императивно-декларативно (с выходом ЛИНК)-функциональном стиле. Это разделить гибко два уровня: хранение и обработка данных + обработка объектов с минимальными усилиями. Дать возможность в полную мощь развернутся императивному стилю, и при этом не потерять выгоду от декларативного.

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

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

C>> Нет никаких фундаментальных причин по которым OODB не могут соперничать с RDB.
IB>Есть. Фундаментальная причина заключается ровно в том, что OODB жестко привязывает поведение и структуру к данным, а срок жизни данных сильно больше навязанного им поведения, и за их время жизни интерпретация меняется по многу раз. Так что привязывать какое-то конкретное поведение к данным — дурная затея.
....
Вы в чем-то правы, знаете. Но тем не поведение и структура привязаны жестко к данным, может быть, с меньшей гранулярностью и меньшей связанностью, но привязаны.
...
IB>Такая объектность может далеко завести, к примеру, работает у нас сейлз в B2B магазине, для него вполне возможен такой граф объектов Region->Customer->Orders->OrderItems->Product->Vendor... ->Region, упс, граф-то цикличный... Хуже другое, после сейлза пришел вендор-менеджер, а ему от кастомера плясать не интересно, ему граф-то нужен ровно обратный Vendor->Products->OrderItems->Order->Customer. И это мы еще на какого-нибудь логистика не посмотрели, у которого регионы и счета кастомера начинаются прямо от OrderItems и конкретный заказ ему не интересен ему важны все OrderItems до четырех часов сегодняшнего дня, чтобы доставку на завтра спланировать по всем адресам.

Обратите внимание, что вы сами выделили те данные и сущности, интерпретация которых не меняется в зависимости от графа, в котором они находятся. А графы — да черт с ними, графы пусть будут произвольными.

Если вернутся к вопросу преобразования данных — то да, согласен с вами, что данные необходимо бывает и группировать, и вычислять новые данные и т.п.
Но, как правило, эти данные статические. Если в приложении, грубо говоря, нужно только строить по данным отчеты — то там не нужны ОРМ и т.п.

Однако, ситуация меняется, когда данные нужно обрабатывать, то есть когда выделяются такие вот сущности типа Customer->Orders->OrderItems->Product->Vendor... ->Region, и эти сущности нужно редактировать, передавать их как параметры, вызывать какие-нибуть их методы (если они есть). А если к этому нужно добавить и пользовательский интерфейс соответсвующий, и валидацию ввода, и метаданные, и еще чего-нибудь... К данным это добавить тяжелее. Согласитесь. Потому что они "просто данные". Может быть, это и не нужно вам. Можно, также всегда сделать так, что это будет ненужно.

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

ST>Но суть то не в этом — суть в том, что ОРМ стремится к идеалу, той самой пресловутой persistence ignorance. Как и СУБД стремится к INDEX IGNORANCE, HINTS IGNORANCE и т.п.

Архитектура может быть идеальной, но позволять криво себя использовать. Если кривое использование такой архитектуры происходит с завидной регулярностью, то это становится проблемой самой архитекруры и такую архитектуру можно смело называть кривой.

В этом и есть главная проблема ORM. Предлагаемые решения позволяют себя криво использовать и часто даже подталкивают к этому.

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

IT>Архитектура может быть идеальной, но позволять криво себя использовать. Если кривое использование такой архитектуры происходит с завидной регулярностью, то это становится проблемой самой архитекруры и такую архитектуру можно смело называть кривой.
Ага. Нужно оставить только лом — его только по назначению можно использовать.

IT>В этом и есть главная проблема ORM. Предлагаемые решения позволяют себя криво использовать и часто даже подталкивают к этому.
Что самое прикольное, то даже MS поняла, что ORM делает LINQ2SQL и прочие низкоуровневые технологии не особо нужным. Всё в точности, как я и говорил когда-то.

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

IT>>Архитектура может быть идеальной, но позволять криво себя использовать. Если кривое использование такой архитектуры происходит с завидной регулярностью, то это становится проблемой самой архитекруры и такую архитектуру можно смело называть кривой.
C>Ага. Нужно оставить только лом — его только по назначению можно использовать.

С ломом это к Дворкину. Решение должно быть защищено от неправильного использования. Или ты с этим не согласен.

IT>>В этом и есть главная проблема ORM. Предлагаемые решения позволяют себя криво использовать и часто даже подталкивают к этому.
C>Что самое прикольное, то даже MS поняла, что ORM делает LINQ2SQL и прочие низкоуровневые технологии не особо нужным. Всё в точности, как я и говорил когда-то.

Вот не надо. MS уже не однократно доказывала, что может как понять, так потом и перепонять. В своё время датасеты проталкивались как единственно возможное решение в области работы с БД. Что-то я последнее время про них совсем не слышу. Сольют L2S и EF и если получится такая же лажа как Hibernate, то перепоймут и сделают как надо.

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

C>>Ага. Нужно оставить только лом — его только по назначению можно использовать.
IT>С ломом это к Дворкину. Решение должно быть защищено от неправильного использования. Или ты с этим не согласен.
Но не до такой степени, что при этом становится бесполезным.

IT>Вот не надо. MS уже не однократно доказывала, что может как понять, так потом и перепонять. В своё время датасеты проталкивались как единственно возможное решение в области работы с БД. Что-то я последнее время про них совсем не слышу. Сольют L2S и EF и если получится такая же лажа как Hibernate, то перепоймут и сделают как надо.
Ну вот как перепоймут — так я и окажусь неправ

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

IT>>С ломом это к Дворкину. Решение должно быть защищено от неправильного использования. Или ты с этим не согласен.
C>Но не до такой степени, что при этом становится бесполезным.

Полезность величина субъективная и трудно измеряемая. А вот количество глюков в багтреккере или проведённые в отладчике часы легко можно сосчитать.

IT>>Вот не надо. MS уже не однократно доказывала, что может как понять, так потом и перепонять. В своё время датасеты проталкивались как единственно возможное решение в области работы с БД. Что-то я последнее время про них совсем не слышу. Сольют L2S и EF и если получится такая же лажа как Hibernate, то перепоймут и сделают как надо.
C>Ну вот как перепоймут — так я и окажусь неправ

Да ты уже неправ, защищая решения, в которые их проблемность заложена в саму архитектуру.

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

C>>Но не до такой степени, что при этом становится бесполезным.
IT>Полезность величина субъективная и трудно измеряемая. А вот количество глюков в багтреккере или проведённые в отладчике часы легко можно сосчитать.
Ну сосчитал, и что?

C>>Ну вот как перепоймут — так я и окажусь неправ
IT>Да ты уже неправ, защищая решения, в которые их проблемность заложена в саму архитектуру.
Так это вообще ВСЕ решения.

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

IT>>Полезность величина субъективная и трудно измеряемая. А вот количество глюков в багтреккере или проведённые в отладчике часы легко можно сосчитать.
C>Ну сосчитал, и что?

То, что проблемы Хайбернейта легко сосчитать, и эта величина далеко не стремится к нулю.

C>>>Ну вот как перепоймут — так я и окажусь неправ
IT>>Да ты уже неправ, защищая решения, в которые их проблемность заложена в саму архитектуру.
C>Так это вообще ВСЕ решения.

Это правда. Любое решение обладает как положительными, так и отрицательными качествами. Но как я уже говорил, если архитектура позволяет криво себя использовать или даже провоцирует к этому, то от такого решения будет больше проблем, чем пользы.

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

C>>Ну сосчитал, и что?
IT>То, что проблемы Хайбернейта легко сосчитать, и эта величина далеко не стремится к нулю.
Только при это Hibernate ещё и даёт нехилый плюс в производительности труда.

C>>Так это вообще ВСЕ решения.
IT>Это правда. Любое решение обладает как положительными, так и отрицательными качествами. Но как я уже говорил, если архитектура позволяет криво себя использовать или даже провоцирует к этому, то от такого решения будет больше проблем, чем пользы.
Тот же .NET можно использовать ТАК криво, что он просто будет под углом 90 градусов стоять. И что дальше? Перевес от использования managed-языка и нормальной библиотеки превышает потери от кривоты. Вот та же ситуация с Hibernate и ORM вообще.

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

C>>>Ну сосчитал, и что?
IT>>То, что проблемы Хайбернейта легко сосчитать, и эта величина далеко не стремится к нулю.
C>Только при это Hibernate ещё и даёт нехилый плюс в производительности труда.

BLToolkit тоже даёт мне нехилый плюс, но при этом без побочных эффектов. Побочные эффекты нужно выявлять и устранять. Ты же пытаешься их оправдать. И это не правильно. Скажи просто — Hibernate классная либа, но некоторые решения в ней на редкость уродские, и на этом наша дискуссия прекратится

IT>>Это правда. Любое решение обладает как положительными, так и отрицательными качествами. Но как я уже говорил, если архитектура позволяет криво себя использовать или даже провоцирует к этому, то от такого решения будет больше проблем, чем пользы.
C>Тот же .NET можно использовать ТАК криво, что он просто будет под углом 90 градусов стоять.

Например? Только не надо копировать откровенно кривые решения с http://thedailywtf.com/.

C>И что дальше? Перевес от использования managed-языка и нормальной библиотеки превышает потери от кривоты. Вот та же ситуация с Hibernate и ORM вообще.

Зачем упорствовать? Недавно тут был целый тред, где тебе популярно разъяснили все проблемы ORM. Не стоит уподобляться всяким лойдам, которые с достойной только дебилам упорством задают одни и те же вопросы, на ответы на эти же вопросы.

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

IT>BLToolkit тоже даёт мне нехилый плюс, но при этом без побочных эффектов. Побочные эффекты нужно выявлять и устранять. Ты же пытаешься их оправдать. И это не правильно. Скажи просто — Hibernate классная либа, но некоторые решения в ней на редкость уродские, и на этом наша дискуссия прекратится
Я сравнивал на практике [N]Hibernate с BLToolkit, iBatis и датасетами. Hibernate уверенно лидирует.

C>>Тот же .NET можно использовать ТАК криво, что он просто будет под углом 90 градусов стоять.
IT>Например? Только не надо копировать откровенно кривые решения с http://thedailywtf.com/.
Например, наделать memory leak'ов, считая что их не может быть в принципе.

C>>И что дальше? Перевес от использования managed-языка и нормальной библиотеки превышает потери от кривоты. Вот та же ситуация с Hibernate и ORM вообще.
IT>Зачем упорствовать? Недавно тут был целый тред, где тебе популярно разъяснили все проблемы ORM. Не стоит уподобляться всяким лойдам, которые с достойной только дебилам упорством задают одни и те же вопросы, на ответы на эти же вопросы.
Ну вот вижу, что проект сильно ускорился после введения Hibernate вместо iBatis. Реальный эффект, однако. Делаю вывод: Hibernate увеличивает производительность труда.

До MS тоже это дошло, и они придумали EF.

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

C>Я сравнивал на практике [N]Hibernate с BLToolkit, iBatis и датасетами. Hibernate уверенно лидирует.

Лидирует в чём?

C>Например, наделать memory leak'ов, считая что их не может быть в принципе.

Ликов не может быть в принципе. Но можно зацепить объекты за статические переменные или за события и тогда они не будут освобождены никогда. Но это не лики, это проблема дизайна.

C>Ну вот вижу, что проект сильно ускорился после введения Hibernate вместо iBatis. Реальный эффект, однако. Делаю вывод: Hibernate увеличивает производительность труда.

Я не сомневаюсь в правильности твоего вывода. Но это не делает эту технологию менее проблемной.

C>До MS тоже это дошло, и они придумали EF.

Я тебе уже говорил, MS много чего придумывает. Но не всё что придумывает MS гениально и становится востребованным. Могу привести ешё один пример — WWF, зачётная технология, но на практике для небольших проектов высоковат уровень вхождения, для больших высоковат уровень поддержки.

Что будет с EF посмотрим. Мой прогноз — мыши плакали, кололись, но продолжали жрать кактус

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

C>>Я сравнивал на практике [N]Hibernate с BLToolkit, iBatis и датасетами. Hibernate уверенно лидирует.
IT>Лидирует в чём?
В скорости разработки и цене поддержки.

C>>Например, наделать memory leak'ов, считая что их не может быть в принципе.
IT>Ликов не может быть в принципе. Но можно зацепить объекты за статические переменные или за события и тогда они не будут освобождены никогда.
Это обычно и называют "memory leak"'ами в managed-приложения.

IT>Но это не лики, это проблема дизайна.
Это я и имею в виду.

C>>Ну вот вижу, что проект сильно ускорился после введения Hibernate вместо iBatis. Реальный эффект, однако. Делаю вывод: Hibernate увеличивает производительность труда.
IT>Я не сомневаюсь в правильности твоего вывода. Но это не делает эту технологию менее проблемной.
Если технология проблемная, но работает, то она не проблемная

IT>Я тебе уже говорил, MS много чего придумывает. Но не всё что придумывает MS гениально и становится востребованным. Могу привести ешё один пример — WWF, зачётная технология, но на практике для небольших проектов высоковат уровень вхождения, для больших высоковат уровень поддержки.
WWF просто сам по себе достаточно нишевая технология.

IT>Что будет с EF посмотрим. Мой прогноз — мыши плакали, кололись, но продолжали жрать кактус
Мой прогноз: мы увидим дальнейшее движение в сторону от баз данных и голого SQL к более высокоуровневым средствам. EF будут совершенствовать, возможно интегрировав в SQL Server частичную поддержку для средств ООП.

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

C>Мой прогноз: мы увидим дальнейшее движение в сторону от баз данных и голого SQL к более высокоуровневым средствам. EF будут совершенствовать, возможно интегрировав в SQL Server частичную поддержку для средств ООП.

Зная примерно, что ис себя представляет тим, который EF занимается, я бы тебе не советовал особо на это рассчитывать.
Кстати, какое то время это чудо пытались как раз mssql team спихнуть, но те от него отпихались руками и ногами.