День добрый.

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

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

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

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

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

Ошибаетесь. Это просто разные вещи.

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

Вероятно, имеется в виду Linq2SQL. Если Вас устраивают те запросы, которые он генерирует, можете использовать.

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

Можно обойтись. Linq to SQL как раз заточен под такие "быстрые" сценарии.

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

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

Linq по своей сути отличается от NHibernate. А вот что можно сравнивать с NHibernate так это ADO Entity Framework, но его пока еще не выпустили.

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

Если бы я делал с нуля проект, то использовал бы только Linq. Кстати, есть возможность посмотреть, в какие именно SQL-запросы преобразовываются твои выражения на Linq, если волнует вопрос производительности, так что все это контролируемо. Также, никто не мешает получать в Linq результаты вызовова хранимок из БД, если например запрос сложный и надо его на уровне БД реализовать строго определенным образом.

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

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

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


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

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

Linq не является ORM. Linq это просто язык запросов. Кстати, есть Linq to NHibernate.

Если сравнивать с NHibernate, то только Entity Framework и пока не в пользу EF.

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

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

z3d>Linq по своей сути отличается от NHibernate. А вот что можно сравнивать с NHibernate так это ADO Entity Framework, но его пока еще не выпустили.

Вообще-то EF есть в поставке VS2008 SP1.

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

kuj>Linq не является ORM. Linq это просто язык запросов.
Та его часть, которая DLINQ (или по другому Linq2Sql) вполне справляется с простейшими задачами ORM:
— маппинг полей классов на поля таблиц как с помошью аттрибутов, так и XML файлов описаний.
— очень просто реализуются операции типа CRUD(L).
Глубже просто не копал пока за ненадобностью.

kuj>Если сравнивать с NHibernate, то только Entity Framework и пока не в пользу EF.
Это не подлежит сомнению, но всем ли нужен этот гигант? У LINQ очень низкий уровень вхождения, имхо. Мне хватило пробежать глазами две книжки книжки на английском за один вечер. Это позволяет его действительно быстро встроить в свой проект и при этом не потерять контроль на тем, что же там внутри происходит.

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

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

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

Большинство примеров по ASP.NET в MSDN все еще пишутся с применением различных DataSource. Например, пришлось немного попотеть, даже просто с прикруткой обычного программного датабиндинга к ListView с DataPager'ами. То одно не работало, то другое от малейшего чиха отваливалось.

С другой стороны после знакомства с Linq старый добрый ObjectDataSource кажется ну совсем тупым и никчемным.

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

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

kuj>Linq не является ORM. Linq это просто язык запросов. Кстати, есть Linq to NHibernate.

Имелось в виду Linq2Sql, конечно... А он несомненно является намного более удобным и простым в использовании ORM. Так что думаю гвоздь все-таки забил? Что скажете?

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

kuj>>Linq не является ORM. Linq это просто язык запросов.
SE>Та его часть, которая DLINQ (или по другому Linq2Sql) вполне справляется с простейшими задачами ORM:
SE>- маппинг полей классов на поля таблиц как с помошью аттрибутов, так и XML файлов описаний.
SE>- очень просто реализуются операции типа CRUD(L).
SE>Глубже просто не копал пока за ненадобностью.
Отсутствуют:
наследование
поддержка value-типов
коллекции только EnitySet (нет даже банального словаря)
SaveOrUpdate механизм(!)
timespan
распределенное кэширование

Очень неудобно работать с транзакциями вне контекста.

kuj>>Если сравнивать с NHibernate, то только Entity Framework и пока не в пользу EF.
SE>Это не подлежит сомнению, но всем ли нужен этот гигант? У LINQ очень низкий уровень вхождения, имхо. Мне хватило пробежать глазами две книжки книжки на английском за один вечер. Это позволяет его действительно быстро встроить в свой проект и при этом не потерять контроль на тем, что же там внутри происходит.

NHibernate очень прост в использовании в простых проектах в действительности.
Есть масса книг, примеров, отличная подробная документация. Есть и обертки типа Castle ActiveRecord (паттерн ActiveRecord из Ruby on Rails)...

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

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

Нет такого стандарта в прироже. И не будет.

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

Ошибаешься.

А> Т.е. с появлением технологии Linq, NHibernate теряет всякий смысл?

Нет.

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

Если уж LINQ в проекте применяется — лучше только через него.

А> В каких случаях что использовать?

Это очень многофакторный вопрос.

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

Нет, не значит.

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


kuj>>Linq не является ORM. Linq это просто язык запросов. Кстати, есть Linq to NHibernate.

А>Имелось в виду Linq2Sql, конечно... А он несомненно является намного более удобным и простым в использовании ORM. Так что думаю гвоздь все-таки забил? Что скажете?

Скажу что Вы плохо понимаете то о чем говорите.

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

kuj>Отсутствуют:
kuj>наследование
kuj>поддержка value-типов
kuj>распределенное кэширование
Это все положительные стороны.

kuj>SaveOrUpdate механизм(!)
Есть.

kuj>Очень неудобно работать с транзакциями вне контекста.
И не нужно этого делать.

kuj>NHibernate очень прост в использовании в простых проектах в действительности.
Не прост, в действительности.

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

kuj>>Отсутствуют:
kuj>>наследование
kuj>>поддержка value-типов
kuj>>распределенное кэширование
IB>Это все положительные стороны.
Поясни.

kuj>>SaveOrUpdate механизм(!)
IB>Есть.
Нет.

http://www.nablasoft.com/alkampfer/index.php/2008/03/01/linq-to-sqlworking-with-detatched-object/

kuj>>Очень неудобно работать с транзакциями вне контекста.
IB>И не нужно этого делать.
Работать с транзакциями? Таки нужно.

kuj>>NHibernate очень прост в использовании в простых проектах в действительности.
IB>Не прост, в действительности.

И что же там такого непростого?

С использованием ActiveRecord все вообще элементарно.

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

kuj>Поясни.
Все это совершенно лишние конструкции в lightweight ORM, коим является LINQ. Вообщем, слава байту, что ничего этого там нет.

kuj>Нет.
Ну ладно, нет в том виде, в котором это привыкли видеть в NHibernate, что тоже плюс.

kuj>Работать с транзакциями? Таки нужно.
Работать с транзакциями вне контекста — не нужно.

kuj>И что же там такого непростого?
Все в нем не просто и местами довольно криво.

kuj>С использованием ActiveRecord все вообще элементарно.
Угу, вот обертку над оберткой использовать — вообще отличная идея.

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

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

kuj>>Нет.
IB>Ну ладно, нет в том виде, в котором это привыкли видеть в NHibernate, что тоже плюс.
Чем же это плюс? Что я должен задумываться о persist`е объектов, писать дополнительный низкоуровневый код и т.д.? Что в этом хорошего???

kuj>>Работать с транзакциями? Таки нужно.
IB>Работать с транзакциями вне контекста — не нужно.
Есть случаи когда нужно.

kuj>>И что же там такого непростого?
IB>Все в нем не просто и местами довольно криво.
Что именно криво? Что не просто? Давай с конкретными примерами и контр примерами на Linq2Sql.

kuj>>С использованием ActiveRecord все вообще элементарно.
IB>Угу, вот обертку над оберткой использовать — вообще отличная идея.
Мы и так используем обертку надо оберткой надо оберткой и т.д. Вся архитектура ПО уже много лет как строится по принципу слоев.

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

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

kuj>>>Поясни.
IB>>Все это совершенно лишние конструкции в lightweight ORM, коим является LINQ. Вообщем, слава байту, что ничего этого там нет.
kuj>Linq2sql не является ORM, как я уже упоминал.

Т.е. вы имеете в виду полноценной ORM? Т.к. если придерживатся понятий, то очень даже является: wiki/ORM

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

kuj>Linq2sql не является ORM, как я уже упоминал.
Это вообще вопрос религиозный. Скажем Хайлсберг linq2SQL считает вполне себе ORM-ом, а его мнение, все-таки, по авторитетнее твоего будет, хотя бы в силу авторства..
Поэтому я совершенно сознательно и использую термин lightweight ORM.

kuj>Что до всего остального это очень плохо, что этого там нету.
Очень хорошо, что нет, и очень правильно.

kuj>Нет кэширования — нет scalability, нет поддержки нормальных коллекций для мэппинга — нет гибкости и т.д.
Гибкость и масштабируемость — не задача ORM, это задача приложения. Поэтому меня и озлобляют ORM, которые занимаютсе тем, чем не должны, и в итоге от их "гибкости" только геморрой на всю голову.

kuj>NHibernate дает выбор — использовать или нет.
Лучше бы вообще не было, чем такой выбор.

kuj>Чем же это плюс?
Тем что предлагается подумать и решить задачу по другому.

kuj> Что я должен задумываться о persist`е объектов
Именно.

kuj>Есть случаи когда нужно.
Нету. Есть нежелание сделать по нормальному.

kuj>Что именно криво? Что не просто?
Все, от идеологии до языка запросов.

kuj>Давай с конкретными примерами и контр примерами на Linq2Sql.
Неинтересно.

kuj>Мы и так используем обертку надо оберткой надо оберткой и т.д. Вся архитектура ПО уже много лет как строится по принципу слоев.
Это повод увеличивать количество слоев что ли? В свое время была роскошная картинка — стэк вызовов в EJB при обращении к БД — там больше ста методов набегало, если мне память не изменяет — тоже видимо были любители все слоями оборачивать... Это к стати к вопросу о явовских ORM.. =))
Зачем использовать две сторонние библиотеки сомнительного качества, когда можно использовать одну, которая идет вместе со студией?

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


kuj>>>>Поясни.
IB>>>Все это совершенно лишние конструкции в lightweight ORM, коим является LINQ. Вообщем, слава байту, что ничего этого там нет.
kuj>>Linq2sql не является ORM, как я уже упоминал.

0K>Т.е. вы имеете в виду полноценной ORM? Т.к. если придерживатся понятий, то очень даже является: wiki/ORM

ОО — полиморфизм, инкапсуляция, наследование.

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

IB>Зачем использовать две сторонние библиотеки сомнительного качества, когда можно использовать одну, которая идет вместе со студией?

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

А заявления разнице в качестве хорошо бы комментировать, я понимаю, что тебе лень, но все же.

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

Z>А заявления разнице в качестве хорошо бы комментировать, я понимаю, что тебе лень, но все же.

Сильно сомневаюсь, что г-н IB имеет хоть малейшее представление о таковом.