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

Z>К большому сожалению linq2sql поддерживает только одну СУБД.
А зачем больше?

Z>А заявления разнице в качестве хорошо бы комментировать, я понимаю, что тебе лень, но все же.
Помоему очевидно, что одна библиотека, которая решает конкретную задачу, конкретным способом, будет заведомо качественнее двух библиотек от разных производителей, одна из которых порывается делать все, включая приготовление кофе по расписанию. Разьве нет?

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

Z>>А заявления разнице в качестве хорошо бы комментировать, я понимаю, что тебе лень, но все же.
IB>Помоему очевидно, что одна библиотека, которая решает конкретную задачу, конкретным способом, будет заведомо качественнее двух библиотек от разных производителей, одна из которых порывается делать все, включая приготовление кофе по расписанию. Разьве нет?

Нет.

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

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

Z>>К большому сожалению linq2sql поддерживает только одну СУБД.
IB>А зачем больше?


Z>>А заявления разнице в качестве хорошо бы комментировать, я понимаю, что тебе лень, но все же.
IB>Помоему очевидно, что одна библиотека, которая решает конкретную задачу, конкретным способом, будет заведомо качественнее двух библиотек от разных производителей, одна из которых порывается делать все, включая приготовление кофе по расписанию. Разьве нет?

Меня не особо интересует качество ActiveRecord. Что такого навороченного делает ядро NHibernate, чтобы это можно было сравнить с приготовлением кофе? Оно умеет маппить результат сиквел запроса в объекты, делать сиквел запрос из самодельного аналога expression tree и из своего языка запросов. Практически все это умеет делать и linq, только малость беднее функционалом.

Про заведомо качественнее не согласен. Хотя про "очевидно" мы уже спорили с тобой, безрезультатно правда

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

Z> Что такого навороченного делает ядро NHibernate, чтобы это можно было сравнить с приготовлением кофе?
Кеш, LL и прочие приседания, которые к мапингу объектов на БД и обратно, имеют весьма посредственное отношение.

Z>Оно умеет маппить результат сиквел запроса в объекты,
Вот если б он только этим и ограничился, я бы тогда с ним смирился.

Z>Практически все это умеет делать и linq, только малость беднее функционалом.
Мой поинт в том, что этот функционал — лишний. Этот функционал направлен как раз на persistent ignorance, а игнорировать это дело нельзя.
Но народ ленив и пытается вообще забыть про СУБД, пользуясь этим функционалом где надо и не надо, последствия чего бывают довольно печальны.

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

IB>>Все это совершенно лишние конструкции в lightweight ORM, коим является LINQ. Вообщем, слава байту, что ничего этого там нет.
kuj>Linq2sql не является ORM, как я уже упоминал. Как минимум из-за отсутствия наследования.
Вообще-то в Linq2Sql есть минимальная поддержка наследования. Зачем она только — непонятно.

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

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

Z>> Что такого навороченного делает ядро NHibernate, чтобы это можно было сравнить с приготовлением кофе?
IB>Кеш, LL и прочие приседания, которые к мапингу объектов на БД и обратно, имеют весьма посредственное отношение.

LL в линке тоже есть, контекст тоже что-то кеширует. Кеш второго уровня в NH врядли создаст проблемы если его не использовать. Тем более локально его не поиспользуешь, только на уровне приложения.

Z>>Оно умеет маппить результат сиквел запроса в объекты,
IB>Вот если б он только этим и ограничился, я бы тогда с ним смирился.

С LL и кешем сессии вроде все просто, что еще такого страшного умеет NH?

Z>>Практически все это умеет делать и linq, только малость беднее функционалом.
IB>Мой поинт в том, что этот функционал — лишний. Этот функционал направлен как раз на persistent ignorance, а игнорировать это дело нельзя.
IB>Но народ ленив и пытается вообще забыть про СУБД, пользуясь этим функционалом где надо и не надо, последствия чего бывают довольно печальны.

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

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

Z>Кеш второго уровня в NH врядли создаст проблемы если его не использовать.
Зачем он тогда нужен?

Z>С LL и кешем сессии вроде все просто, что еще такого страшного умеет NH?
Страшно, что он это умеет. Страшен его язык запросов, страшна идеология того самого присловутого persistance ignorance, ect...

Z>Т.е. проблема инструмента в том, что ты не можешь ограничить его использование в каких-то рамках?
Проблема в том, что он провоцирует забывать о том, что данные лежат во внешнем хранилище.

Z>Не страшно давать народу MSVS? Там же такого кода понаписать можно
Я видел удачные продукты полученные при использовании MSVS, но из них не было ни одного с использованием NH.

В тему Linq vs NHibernate и запросов:
Раньше работал с NHibernate проблем не было, с линком сейчас есть проблема — не могу решить. Необходимо объединять таблицы в нетипизированном виде. В NHibernate это просто решается как HQL, так и критериями. А в линк такое, вообще, возможно? Запостил топик, пока никто не ответил
http://www.rsdn.ru/forum/message/3096240.1.aspx

Автор: FreddieM
Дата: 09.09.08

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

Z>С LL и кешем сессии вроде все просто, что еще такого страшного умеет NH?

Вопрос собственно не в том, что страшного умеет NH. Вопрос в том, что умеет NH, чего не умеет Linq2Sql — и насколько это важно. Я пока стоящих аргументов за NH не видел.

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

Кэр>Здравствуйте, Ziaw, Вы писали:

Z>>С LL и кешем сессии вроде все просто, что еще такого страшного умеет NH?

Кэр>Вопрос собственно не в том, что страшного умеет NH. Вопрос в том, что умеет NH, чего не умеет Linq2Sql — и насколько это важно. Я пока стоящих аргументов за NH не видел.

Вопрос был как раз в том, что NH умеет слишком много всего, включая варку кофе Я не агитирую за NH, я знаю недостатки и достоинства этого инструмента. Я не согласен с некоторыми утверждениями холивара против данной библотеки и ORM в целом.

Мне в линке не хватает гибкости и контроля маппингов и поддержки оракла с фаербердом, отсутствие остальных фич NH я готов терпеть за удобство типизации и простоту грануляции запрашиваемых данных.

Здравствуйте, Аноним, Вы писали:

А>День добрый.

А>Заметил, что появился Linq и родственные технологии и активно продвигается. Как теперь канонично работать с базой данных (по стандарту, так сказать)?

А>1. Какак я понимаю, Linq забил последний гвоздь в крышку гроба NHibernate, или я ошибаюсь? Т.е. с появлением технологии Linq, NHibernate теряет всякий смысл?

А>2. Далее. Linq в какой-то степени заменяет SQL-запросы. Использовать ли теперь SQL-запросы или все делать через Linq? В каких случаях что использовать?

А>3. Если мне максимально быстро нужно сделать сайт с базой. Время запросов имеет не большой смысл -- главное быстро создать сайт. Значит ли это, что мне не нужно использовать ни хранимые процедуры, ни SQL-запросы и можно обойтись только Linq to SQL и Linq?

Скорее всего — это не стандарт, а определенная нотация кода.
1)Последний гвоздь в крышку гроба NHibernate забил Ado.Net Entity Framework.
Уже скачал и поставил — просто чудо. Релиз вместе с VS 2008 SP1 вышел.
и теперь конечно исп-е NHibernate ставится под сомнение.
2)Если нужна высокая производительность, ну прям действительно важен
выйгрыш в 10% или более, то конечно исп-ся IDataReader в паре со
строковыми запросами на SQL,
ну а ежели нет, тогда зачем мучится — Linq to SQL и все ОК.
3)Конечно можно обойтись Linq to SQL.
(Там очень интересная модель выполнения и построения запросов,
чем впринципе так сильно отличается Linq to SQL от Linq to Objects и Linq to ...)

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

M>1)Последний гвоздь в крышку гроба NHibernate забил Ado.Net Entity Framework.

Возможно и забьет, но не в первой версии. Первая версия EF 1) нарушает принцип persistence ignorance, 2) не имеет implicit lazy loading. Есть еще ряд проблем, но не столь существенных.

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

Давай по новой.. =)

C> Первая версия EF 1) нарушает принцип persistence ignorance, 2) не имеет implicit lazy loading.
Это все положительные стороны...
Недостатки будут?

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

C>> Первая версия EF 1) нарушает принцип persistence ignorance, 2) не имеет implicit lazy loading.
IB>Это все положительные стороны...
IB>Недостатки будут?
С Вами не возможно спорить. Вы отрицаете любое утверждение без какой-либо аргументации. Думаю пора завязывать с этим непродуктивным спором.

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

C>С Вами не возможно спорить.
Еще бы, я же прав..

C> Вы отрицаете любое утверждение без какой-либо аргументации.
Я, взволнован. Я аргументов ворох привел, а в ответ получил отмазки из серии "у меня все работает". Не конструктивненько.

C> Думаю пора завязывать с этим непродуктивным спором.
Сломался?

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


C>>С Вами не возможно спорить.
IB>Еще бы, я же прав..

C>> Вы отрицаете любое утверждение без какой-либо аргументации.
IB>Я, взволнован. Я аргументов ворох привел, а в ответ получил отмазки из серии "у меня все работает". Не конструктивненько.

C>> Думаю пора завязывать с этим непродуктивным спором.
IB>Сломался?

Да-да, Вы правы, я сломался. Только не волнуйтесь так. Это вредно для здоровья.

Здравствуйте, criosray, Вы писали:
Просто вся аргументация была уже приведена неоднократно, и даже совсем недавно. Заниматься повторением аргументов каждому новоприбывшему в топик терпения хватает не у многих.
Вкратце могу отослать к другому термину — leaky abstractions. Вот когда абстракции lazy loading и persistence ignorance становятся leaky, тут и вылезают проблемы с масштабированием и производительностью. А эти абстракции протекают легко и часто, что и делает их плохими, в отличие от, скажем, абстракции MSIL.

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

S>Просто вся аргументация была уже приведена неоднократно, и даже совсем недавно. Заниматься повторением аргументов каждому новоприбывшему в топик терпения хватает не у многих.

Не занимайтесь — никто Вас не заставляет.

S>Вкратце могу отослать к другому термину — leaky abstractions.

Спасибо я знаю что такое leaky abstractions. В любой архитектуре могут появиться leaky abstractions. Единственная leaky abstraction в NHibernate это возможность использования SQL напрямую. Честно говоря, даже не знаю зачем ее оставили. На моей практике ни разу не потребовалось прибегать к ней.

Здравствуйте, criosray, Вы писали:
C>Спасибо я знаю что такое leaky abstractions.
Непохоже.
C> В любой архитектуре могут появиться leaky abstractions.
Абстракции в архитектуре есть всегда. Вообще вся архитектура — это выбор абстракций. Ты имел в виду, что любая абстракция может стать leaky?
C>Единственная leaky abstraction в NHibernate это возможность использования SQL напрямую. Честно говоря, даже не знаю зачем ее оставили. На моей практике ни разу не потребовалось прибегать к ней.
Непохоже, что ты понимаешь, что такое leaky abstraction. Тебе понятно, почему lazy loading и persistence ignorance — leaky? Если непонятно, то что именно?

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

C>>Спасибо я знаю что такое leaky abstractions.
S>Непохоже.
Вы считаете, что Вы знаете что такое leaky abstractions? Не похоже. Вот именно.
C>> В любой архитектуре могут появиться leaky abstractions.
S>Абстракции в архитектуре есть всегда. Вообще вся архитектура — это выбор абстракций. Ты имел в виду, что любая абстракция может стать leaky?
Конечно.
C>>Единственная leaky abstraction в NHibernate это возможность использования SQL напрямую. Честно говоря, даже не знаю зачем ее оставили. На моей практике ни разу не потребовалось прибегать к ней.
S>Непохоже, что ты понимаешь, что такое leaky abstraction. Тебе понятно, почему lazy loading и persistence ignorance — leaky? Если непонятно, то что именно?
Вы это серьезно? Ну и фантазия у Вас...