Со того времени, когда понял что же такое Linq2Sql в голове жужжит мысль о противопоставлении ORM'ов типа hibernate и Linq-подхода.
Т.е. для меня налицо два совершенно разных направления:
1. Классический ORM: делаем класс, объявляем правила маппинга. Экземпляры данного класса являются интересующими объектами. Такой путь зарождает в себе причину появления отложенной загрузки из БД, поскольку не все поля нам всегда нужны.
2. ORM в стиле Linq: построение каркаса запроса и формата выдачи данных на нативном языке, генерация sql-выражения точно соответствующего каркасу запроса, динамический маппинг на динамический класс.

И вот мне непонятно — чем может быть привлекателен классический ORM по сравнению с LinqORM? Я сейчас не хочу привязываться с конкретным реализациям и сопоставлять, к примеру, hibernate и Linq2SomeDatabase — я хотел бы просто сравнить два подхода к связыванию данных с объектами. На данный момент Linq2Sql-подход мне представляется идеальнейшим подходом, который делает код похожим на тот же PL/Sql плюс рядом вся инфраструктура конкретного языка, к которой уже так привык. Ужасным кажется только неудачность названий. Linq2Sql — это конкретное решение, завязанное на конкретную СУБД. Просто Linq — недобор, это всего лишь способ обращения к данным. Должно быть какое-то промежуточное название, типа Linq2Database, чтобы выражать общий принцип, семейство продуктов — а такого нет.
Кстати, было бы неплохо узнать у кого microsoft стырил идею Linq2Sql и что есть подобного кроссплатформенного и устоявшегося в остальном — немелкомягком мире?

Итого вопрос: какие недостатки у Linq-подхода?
P.S. кажется можно было бы сразу помещать вопрос в СВ — но, надеюсь, пронесёт.

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

N>Итого вопрос: какие недостатки у Linq-подхода?

По мнению приверженцев классических ORM — это отсутствие Entity Services.

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

N>И вот мне непонятно — чем может быть привлекателен классический ORM по сравнению с LinqORM?
Пока в Linq-провайдеры не включили DML он будет отчасти похож на классический ORM.

N>Просто Linq — недобор, это всего лишь способ обращения к данным. Должно быть какое-то промежуточное название, типа Linq2Database, чтобы выражать общий принцип, семейство продуктов — а такого нет.
Неправда, есть Entity Framework и Linq2Entities.

N>Итого вопрос: какие недостатки у Linq-подхода?
Cложности реализации. До сих пор ни один провайдер не дотянул до реализации DML.

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

G>Cложности реализации. До сих пор ни один провайдер не дотянул до реализации DML.

Здесь. Раздел DML операции.

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

N>Т.е. для меня налицо два совершенно разных направления:
N>1. Классический ORM: делаем класс, объявляем правила маппинга. Экземпляры данного класса являются интересующими объектами. Такой путь зарождает в себе причину появления отложенной загрузки из БД, поскольку не все поля нам всегда нужны.
N>2. ORM в стиле Linq: построение каркаса запроса и формата выдачи данных на нативном языке, генерация sql-выражения точно соответствующего каркасу запроса, динамический маппинг на динамический класс.

N>И вот мне непонятно — чем может быть привлекателен классический ORM по сравнению с LinqORM? Я сейчас не хочу привязываться с конкретным реализациям и сопоставлять, к примеру, hibernate и Linq2SomeDatabase — я хотел бы просто сравнить два подхода к связыванию данных с объектами.

Да одно это направление, просто классические ORM проектировались и разрабатывались до появления анонимных классов и экспрешенов. В том же гибернейте генерация sql точно соответствует каркасу запроса, другое дело, что использовать загрузку только необходимых данных без поддержки языка очень неудобно. Сейчас большинство классических ORM поддерживает linq подобный доступ к данным. Так что эта разница уже стерлась.

Но есть действительно другой подход, его предлагает пока только bltoolkit — отказ от трекинга изменений и управление DML запросами вручную. Что, на мой взгляд, очень даже здорово.

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

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

N>>Итого вопрос: какие недостатки у Linq-подхода?

IT>По мнению приверженцев классических ORM — это отсутствие Entity Services.

Так они вроде как везде есть.
IdentityMap, ChangeTracking, UnitOfWork, Lazy/Deferred Loading, NavigationProperties.
Все это есть и в Linq2Sql и провайдерах на его основе, и в EntityFramework 1.0/2.0, и в NHibernate...

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

IT>>По мнению приверженцев классических ORM — это отсутствие Entity Services.

А>Так они вроде как везде есть.

В Linq2Sql это всё в зачаточном состоянии и интересен многим он прежде всего был именно по этой причине.

А>IdentityMap, ChangeTracking, UnitOfWork, Lazy/Deferred Loading, NavigationProperties.
А>Все это есть и в Linq2Sql и провайдерах на его основе,

А какие есть провайдеры на его основе?

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

IT>В Linq2Sql это всё в зачаточном состоянии и интересен многим он прежде всего был именно по этой причине.

Что именно? Все перечисленное там есть по умолчанию.

IT>А какие есть провайдеры на его основе?

Была такая калька с него — DbLinq — для поддержки всех остальных БД, о существовании которых МС любезно забыла.

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

IT>>В Linq2Sql это всё в зачаточном состоянии и интересен многим он прежде всего был именно по этой причине.
А>Что именно? Все перечисленное там есть по умолчанию.

Всё перечисленное можно сделать и самому. Вопрос не в этом.

IT>>А какие есть провайдеры на его основе?

А>Была такая калька с него — DbLinq — для поддержки всех остальных БД, о существовании которых МС любезно забыла.

Он и сейчас есть и даже развивается. Только это не на основе Linq2Sql, а совершенно отдельная поделка.

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

N>Итого вопрос: какие недостатки у Linq-подхода?

Насколько я помню, linq2sql отображает обьекты напрямую на таблицы, что приводит к необходимости иметь структуру таблиц в точности совпадающей со структурой обьектов, я поэтому вообще не представляю, как можно построить богатую рич-модель (с наследованиями и пр.) — по всей видимости никак, что очень большой минус

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

N>сопоставлять, к примеру, hibernate и Linq2SomeDatabase

Так никто их и не сопоставляет. NHibernate прекрасно поддерживает LINQ-запросы.

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

N>>Итого вопрос: какие недостатки у Linq-подхода?

А>Насколько я помню, linq2sql отображает обьекты напрямую на таблицы, что приводит к необходимости иметь структуру таблиц в точности совпадающей со структурой обьектов, я поэтому вообще не представляю, как можно построить богатую рич-модель (с наследованиями и пр.) — по всей видимости никак, что очень большой минус

Это вопрос предпочтений. Для кого-то большой минус, для кого-то огромныый плюс.

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

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

N>>сопоставлять, к примеру, hibernate и Linq2SomeDatabase

U>Так никто их и не сопоставляет. NHibernate прекрасно поддерживает LINQ-запросы.
достаточно взглянуть сюда issues nhibernate linq
чтобы по крайней мере убрать слово "прекрасно".

Прошу прощения за перемешивание порядка в цитате, так последовательнее на мой взгляд будут ответы:

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

Z>Да одно это направление, просто классические ORM проектировались и разрабатывались до появления анонимных классов и экспрешенов. В том же гибернейте генерация sql точно соответствует каркасу запроса, другое дело, что использовать загрузку только необходимых данных без поддержки языка очень неудобно. Сейчас большинство классических ORM поддерживает linq подобный доступ к данным. Так что эта разница уже стерлась.

Тут важно понимать, что загрузка только необходимых данных практически несовместима с Entity Services.

N>>Т.е. для меня налицо два совершенно разных направления:
N>>1. Классический ORM: делаем класс, объявляем правила маппинга. Экземпляры данного класса являются интересующими объектами. Такой путь зарождает в себе причину появления отложенной загрузки из БД, поскольку не все поля нам всегда нужны.
N>>2. ORM в стиле Linq: построение каркаса запроса и формата выдачи данных на нативном языке, генерация sql-выражения точно соответствующего каркасу запроса, динамический маппинг на динамический класс.

N>>И вот мне непонятно — чем может быть привлекателен классический ORM по сравнению с LinqORM? Я сейчас не хочу привязываться с конкретным реализациям и сопоставлять, к примеру, hibernate и Linq2SomeDatabase — я хотел бы просто сравнить два подхода к связыванию данных с объектами.
Вы здесь путаете теплое и мягкое. В Linq2SQL тоже есть навигационные свойства и отложенная загрузка. В "классических" ОРМ тоже можно использовать query comprehehsion (другое дело, что это очень сложно и трудоемко реализовать, поэтому не везде это есть). Линк2Скл популярен именно по причине простоты использования и интегрированности (ну и конечно же из-за того, что это наиболее доступная (потому что встроенная) и достаточно качественная реализация IQueryable<T> провайдера).

Сделайте провайдер такого же уровня для НХибернейта, встройте его в студию, и добавьте диаграммы, на которые можно перетаскивать таблички из Server Explorer — станет он таким же популярным, как и Линк2Скл.

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

N>И вот мне непонятно — чем может быть привлекателен классический ORM по сравнению с LinqORM?

Тем что позволяет создавать ПО работающие с БД даже тем чей мозг поражен прогрессирующим ООП-ом головного мозга.
Есть люди которые без объектов жить не могу. Им и В РСБУД все время мерещатся объекты.

Характерными признаками ООП-а головного мозга являются:
1. Рассуждения о персистентности объектов (жизни после смерти).
2. Тотальный кэш головного мозга (желание закэшировать все и вся с помощью универсального распределенного кэша).
3. Опережающее чтение данных (зачастую раньше их появления).
4. Нелюбовь краткого кода (любят они в циклах БД на клиента читать).

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

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

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

N>>>сопоставлять, к примеру, hibernate и Linq2SomeDatabase

U>>Так никто их и не сопоставляет. NHibernate прекрасно поддерживает LINQ-запросы.
C>достаточно взглянуть сюда issues nhibernate linq
C>чтобы по крайней мере убрать слово "прекрасно".

Полагаю, что тут должно быть уже лучше, чем было