Здравствуйте, VladD2, Вы писали:
VD>А почему собственно только на сервере? Весь кайф абстрации запроса в том, что он одинаково выглядит (и пишется) независимо от того как его будут исполнять. Его даже над датасетами можно применять.
Совершенно верно. На мой вкус, весь кайф как раз в том, что нет подводных камней. Нет ограничения на место исполнения, в том числе можно полностью отдать его в удаленный сервер без потери строгости типизации и прочих прелестей статического контроля.

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

А>>а можешь сказать, что ты используешь как ORM? и как объекты передаёшь клиенту?
IB>Как ORM я не использую ничего..
IB>В качестве маппера по возможности стараюсь использовать BLT

Автор(ы): Игорь Ткачёв
Дата: 01.07.2003
В статье подробно рассматривается состав и способы применения пространства имён Rsdn.Framework.Data, представляющего собой высокоуровневую обёртку над ADO.NET.

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

S>Не будет приза. Оптимизатор не сможет построить вменяемый план по такому запросу. Как только ты сделал complex expression в order by — добро пожаловать в сортировку в памяти. А прямой SQL позволяет воспользоваться индексом.

Ты утверждал что нельзя сделать desc и сложную cортировку без динамического sql.
О сравнении планов речь не шла, речь шла о функционале.

Здравствуйте, снежок, Вы писали:
С>Ты утверждал что нельзя сделать desc и сложную cортировку без динамического sql.
С>О сравнении планов речь не шла, речь шла о функционале.
Не, ну если хочешь — я признаю, что ты немерено крут, а я облажался.

Суть вопроса это не изменит — TSQL получается ужасным и плохо обобщаемым. Кроме того, отлаживать все эти ISNull, обращения ключа и прочие извращения тоже не радость.
Linq по-прежнему позволяет писать гораздо более компактный, надежный и высокопроизводительный код.

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

S>Суть вопроса это не изменит — TSQL получается ужасным и плохо обобщаемым. Кроме того, отлаживать все эти ISNull, обращения ключа и прочие извращения тоже не радость.

Это дело вкуса и привычки, я вот например с ужасом вспоминаю времена когда мне приходилось рефакторить один access-проект мигрированный под mssql. И пока не появился нормальный слой xп и DAL, отладка этого проекта была сущим адом. В профайлере нихрена не было понятно что откуда и почему. Просиживание в VS под отладкой занимало почти весь рабочий день. Запросы постоянно приходилось править и после каждого протестированного исправления — перекомпиляция и выкладывание сборки на сервак. Нет, ну может конечно есть люди спокойно позволяющие себе кидать сборку на сервер по 10 раз в день, отрубая всех, в моих проектах — нет. Ну и что из того что linq-запрос объектный? Сути это не меняет тоже!
Есть девелоперы которые плохо знают t-sql, но есть и еще больше появится девелоперов которые плохо знают linq или применяют его неверно и получим все то же самое, что было раньше c проектами на access-е и fox-е. Все это уже было...
Я вообще не понимаю откуда у вроде бы опытных людей столько оптимизма по поводу новой подделки, которую опять пытаются втюхать через маркетинг?
"Подождите выхода EDF — там все круто"
,"Подождите выхода Astoria — все проблемы с сервисами решаться сами собой"
,"Подождите выхода EDF 2.0 (года через 2, раньше не можем потому что он написан на C# 4.0 и под FW 4.0 где используются супермегапродвинутые дженерики и паралельный linq)"
,"Купите новую VS потому что под старой разрабатывать для FW 4.0 нельзя"
,"Купите новый MSSQL, потому что там новый наикрутейший спермега оптимизатор, справляющийся с любым тупорыло-написанным запросом LINQ".
...список можно продолжить.

S>Linq по-прежнему позволяет писать гораздо более компактный, надежный и высокопроизводительный код.

Никогда обобщенный налету сгенерированный sql-код не был лучше тонко оптимизированного или вручную написанного нормальным девелопером.
И я бы сказал "надеюсь что linq позволит писать гораздо более компактный, надежный и высокопроизводительный код", но пока еще не позволяет, к сожалению. И наличие повсюду LEFT OUTER JOIN-ов и count-ов об этом свидетельствует.

iT>>Как это?? На базовый — просто обычный FOREIGN KEY на общий PK
С>Это для варианта наследования в виде связи 1-к-1, но мы же в последнем посте обсуждали другой вариант — наследования всех атрибутов базовой сущности. В этом варианте внешнего ключа на базовую сущность быть не может, так как в базовой таблице не содержится ничего относящегося к дочерним типам. Видимо ты не совсем правильно понимаешь этот тип наследования или я что то не так объяснил.

Я вообще-то отвечал на это:

С>Меня пугает то, что творится внутри этой таблицы, и кстати, невозможность на уровне таблицы построить constaraint по полю потомка, который должен быть применим только для одного типа. Т.е. в случае SingleTableInheritance применяем constraint либо ко всем типам, либо вообще его не создаем и контролируем его в другом месте.

и я говорил, что все констрейнты как раз отлично строятся в случае SingleTable

Ну да ладно, вроде все уже обсудили

Здравствуйте, Sinclair, Вы писали:
S>Совершенно верно. На мой вкус, весь кайф как раз в том, что нет подводных камней. Нет ограничения на место исполнения, в том числе можно полностью отдать его в удаленный сервер без потери строгости типизации и прочих прелестей статического контроля.

Да, да... нет ограничения на место исполнения...
Теперь представь себе следующую ситуацию, вовсе не редкую, кстати:
У тебя появляется хороший продукт с хорошим функционалом, оракловая БД, промежуточный уровень и интерфейс под .net-ом, работа с БД через linq to oracle, написанный самим ораклом. Все идет не плохо.
Появляется немецкий клиент/партнер, который готов заплатить крупные бабки за продукт и его поддержку.
Шев в восторге, манагеры довольны собой и предвкушают сладкую жизнь...
Единственное что не устраивает клиента — это .net, потому что немцы ох как не любят ms, просто принципиально, и везде хотят java.
У них же, кхе, стандарты корпоративные и транснациональные...
Шеф идет к тебе с вопросом "А можешь? Только они не хотят всяких серверов интеграций, обмена сообщениями, сервисов. Говорят накушались, хватит. Хотят сквозное решение".
Ты — конечно могу, только мне надо повыковыривать изо всех дыр все linq-запросы и прикладной код на основе его и запихнуть во что то иное (stored proc, java stored proc, NHibernate...) потому что linq под явой нету, потом для этого нового кода написать новые unit-тесты и еще кучу всего. Вообщем для нашего наикрутейшего продукта с учтетом того, что надо нанять еще несколько человек в группу, это займет года 2... наверное...
Шеф — "А зачем ты на этот самый..., как его..., лин-ку заточился, ведь есть же проверенные временем решения, паттерны, слои и т. п. Сейчас бы проще было!"
Ты — "А я думал он решит все наши проблемы, сократит написание рутинного кода, стоимость разработки, потом это ж стильно модно, молодежно ".
Шеф — "Понятно, в итоге мы не можем удовлетворить меняющиеся бизнес-требования, не можем поднять продажи и заработать бабла..."

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

С> И пока не появился нормальный слой xп и DAL, отладка этого проекта была сущим адом.
Это вопрос архитетуры, а не используемой библиотеки...

С> Запросы постоянно приходилось править и после каждого протестированного исправления — перекомпиляция и выкладывание сборки на сервак. Нет, ну может конечно есть люди спокойно позволяющие себе кидать сборку на сервер по 10 раз в день, отрубая всех, в моих проектах — нет.
У тебя все проекты правятся по живому? Что тебе мешает все 10 раз посмотреть что происходит на тестовом сервере и выложить в VCS при уходе с работы что получилось, никому не мешая?

C>Ну и что из того что linq-запрос объектный? Сути это не меняет тоже!
Хором тебе уже говорят, что запрос ни разу не объектный, а очень даже реляционный.

С>Я вообще не понимаю откуда у вроде бы опытных людей столько оптимизма по поводу новой подделки,
Наверное неспроста..

С>Никогда обобщенный налету сгенерированный sql-код не был лучше тонко оптимизированного или вручную написанного нормальным девелопером.
Помнится, когда-то тоже самое говорили про ассемблер.

С> И наличие повсюду LEFT OUTER JOIN-ов и count-ов об этом свидетельствует.
Наличие LEFT JOIN-ов и COUNT-ов не свидетельствует ни о чем...

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

С>Теперь представь себе следующую ситуацию,
Бред.

С> вовсе не редкую, кстати:
=)

С>Ты — конечно могу, только мне надо повыковыривать изо всех дыр все linq-запросы и прикладной код на основе его
Что это за "прикладной код на основе"?
Если даже, вдруг, такое случилось, и тебе действительно надо избавиться от .Net, то переписывание запросов будет наименьшей из проблем.

С>> И пока не появился нормальный слой xп и DAL, отладка этого проекта была сущим адом.
IB>Это вопрос архитетуры, а не используемой библиотеки...
Правильно, только вот ваш хваленный linq так и подталкивает вновь все размазывать по слоям, вместо того чтобы иметь вменяемую архитектуру.
С>> Запросы постоянно приходилось править и после каждого протестированного исправления — перекомпиляция и выкладывание сборки на сервак. Нет, ну может конечно есть люди спокойно позволяющие себе кидать сборку на сервер по 10 раз в день, отрубая всех, в моих проектах — нет.
IB>У тебя все проекты правятся по живому? Что тебе мешает все 10 раз посмотреть что происходит на тестовом сервере и выложить в VCS при уходе с работы что получилось, никому не мешая?

В первое время ошибки требовалось править оперативно и сразу выкладывать одно исправление за другим. Такова уж была специфика проекта и его состояние.

C>>Ну и что из того что linq-запрос объектный? Сути это не меняет тоже!
IB>Хором тебе уже говорят, что запрос ни разу не объектный, а очень даже реляционный.
Хором тебе уже готовы кричать, что реляционный он на сервер приходит, а в .net-коде выглядит как подобие объектного, который не каждый сейчас способен граммотно написать.

С>>Я вообще не понимаю откуда у вроде бы опытных людей столько оптимизма по поводу новой подделки,
IB>Наверное неспроста..
Да, не спроста, потому что ms, потому что встроили в свой продукт, потому что маркетологи покричали, блогеры попиарили.
Нет, я вовсе не против идеи как таковой. Удобно для работы с коллекциями.
Но для работы с БД... дайте нормальный родной маппер на хп + bo-библиотеку с биндингом, мне больше ничего не надо. Пусть остальные работаю как им нравится, мне по-фигу, как и остальным на мои проверенные временем подходы.
А так я и до этого в инете мог наковырять с десяток ORM(или назовите как хотите) выполняющих такую же лабуду.

С>>Никогда обобщенный налету сгенерированный sql-код не был лучше тонко оптимизированного или вручную написанного нормальным девелопером.
IB>Помнится, когда-то тоже самое говорили про ассемблер.
Помнится когда-то говорили что программы будут писать роботы, а программисты вымрут как динозавры.
Помнится предрекали светлое будущее MDA, еще много чего помнится...

С>> И наличие повсюду LEFT OUTER JOIN-ов и count-ов об этом свидетельствует.
IB>Наличие LEFT JOIN-ов и COUNT-ов не свидетельствует ни о чем...
Т.е. не будем заморачиваться, просто нагенерим везде внешних соединений, даже если хватает или должо быть внутреннее и все ок? Так да?

С>>Теперь представь себе следующую ситуацию,
IB>Бред.
Бред воспринимать очень сырой продукт как очередную панацею, и повсеместно пиарить его.

С>>Ты — конечно могу, только мне надо повыковыривать изо всех дыр все linq-запросы и прикладной код на основе его
IB>Что это за "прикладной код на основе"?
Как пить дать, столкнешся где-нибудь с намешанной бизнес-логикой с linq-запросами, тогда поговорим.
IB>Если даже, вдруг, такое случилось, и тебе действительно надо избавиться от .Net, то переписывание запросов будет наименьшей из проблем.
Был бы слой хп изначально, не пришлось бы переписывать запросы вообще.
Даже в ситуации смены субд, перегенирировать crud и вручную написанные запросы (например для отчетов) вызвало бы меньше проблем если бы все было оформлено в хп .

Здравствуйте, снежок, Вы писали:
С>Бред воспринимать очень сырой продукт как очередную панацею, и повсеместно пиарить его.
Бред воспринимать позитивные отзывы об очень перспективном продукте как совет немедленно всё бросить и очертя голову переписать всё на нем. Рамки применения Linq2Sql хорошо известны. Вы вообше всю рекламу по телевизору воспринимаете как личное оскорбление? Вон ford fusion оголтелую рекламную кампанию развернул; может попробуем убедиться, что он — говно, путем запихивания в него фундаментного блока? А то иш чо — "вместительным" обозвали. Продукт-то сырой!

С>Как пить дать, столкнешся где-нибудь с намешанной бизнес-логикой с linq-запросами, тогда поговорим.
Ну, вот это я могу понять. Сам я опыта применения линка в масштабных проектах не имею, поэтому о влиянии его на архитектуру в целом судить опасаюсь. Но попробовать хочется.
IB>>Если даже, вдруг, такое случилось, и тебе действительно надо избавиться от .Net, то переписывание запросов будет наименьшей из проблем.
С>Был бы слой хп изначально, не пришлось бы переписывать запросы вообще.
С>Даже в ситуации смены субд, перегенирировать crud и вручную написанные запросы (например для отчетов) вызвало бы меньше проблем если бы все было оформлено в хп .
Вообще-то ты говорил не о ситуации смены СУБД, а о смене дотнета. Не увиливай. Переписать приложение с дотнета на джаву сложно независимо от того, есть у тебя ХП или Linq. Я, конечно, допускаю, что у тебя есть подобный опыт, но если честно, то с трудом. Вот у нас есть продукт существующий в двух code bases — С# и PHP. Ну так стоимость "конверсии" приблизительно равна стоимости написания с нуля. Так что я бы попросил без ля-ля.

С>>Был бы слой хп изначально, не пришлось бы переписывать запросы вообще.
С>>Даже в ситуации смены субд, перегенирировать crud и вручную написанные запросы (например для отчетов) вызвало бы меньше проблем если бы все было оформлено в хп .
S>Вообще-то ты говорил не о ситуации смены СУБД, а о смене дотнета. Не увиливай.
Да я и не увиливаю, просто предположил что можно было бы задать вопрос о поддержке совместимости с несколькими субд.
т.е. другая сторона вопроса (в противовес вопросу .net to java). Вот и высказался не дожидаясь.

>>Так что я бы попросил без ля-ля.
Если изначально такие требования ставятся, то далеко не все так грустно может быть.
Методы для этого есть — аспектное программирование, case-tools и генераторы.
Но если уже готовый продукт требуется конвертить — тут согласен, тяжело. Особенно тяжело когда нагородят тяжело портируемого кода, всяких spring, tapestry, linq опять же

Здравствуйте, снежок, Вы писали:
С>Но если уже готовый продукт требуется конвертить — тут согласен, тяжело. Особенно тяжело когда нагородят тяжело портируемого кода, всяких spring, tapestry, linq опять же
Вполне достаточно наколбасить тяжело портируемый код на диалекте SQL соответствующего вендора. Как переносить XП между Firebird/MSSQL/Oracle? Только полным переписыванием, а зачастую еще и надо синтаксис вызова поменять и т.п.
Вот тут как раз по идее рулят системы, которые не зависят от тяжеловесных хранимок. Какой-нибудь генератор SQL по концептуальной модели переключается на другого провайдера — и поехали. Например, этим генератором может быть линк. Сейчас он заточен исключительно под MS. Но, поскольку система открытая, никто не запретит тебе дописать back-end для оракл и воспользоваться соответствующими преимуществами.
На всякий случай уточню: это в основном теоретические рассуждения. Практику надо смотреть по практике. Пока рано говорить о том, удастся ли улучшить кросс-DB переносимость за счет линка. По сравнению, естественно, с голым ADO.NET — потому, что всякие гибернейты и геномы уже и так предлагают аналогичную переносимость; разве что построена она на text-only *QL запросах, которые тяжело отлаживать и поддерживать из-за отсутствия compile-time проверок.

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

С>Правильно, только вот ваш хваленный linq так и подталкивает вновь все размазывать по слоям,
Никуда он не подталкивает, своя-то голова есть?

С>Хором тебе уже готовы кричать, что реляционный он на сервер приходит, а в .net-коде выглядит как подобие объектного, который не каждый сейчас способен граммотно написать.
Что-то слабоват хор.. Именно в .Net коде нет никакого подобия объектного.

С>Да, не спроста, потому что ms, потому что встроили в свой продукт, потому что маркетологи покричали, блогеры попиарили.
Ага, и один ты, такой умный, всех раскусил..

С>Но для работы с БД... дайте нормальный родной маппер на хп
linq тебе его вполне заменит.

С>А так я и до этого в инете мог наковырять с десяток ORM(или назовите как хотите) выполняющих такую же лабуду.
Не мог

С>Помнится предрекали светлое будущее MDA, еще много чего помнится...
Ну, мы-то не о будущем говорим, а о настоящем. В настоящее же время 90% автогенеренного линком SQL работает good enough.

С>Т.е. не будем заморачиваться,
Не то чтобы совсем, заморачиваться будем только в тех случаях, где это оправдано.

C> просто нагенерим везде внешних соединений, даже если хватает или должо быть внутреннее и все ок? Так да?
Если тебя это так заботит, тебе ничто не мешает по прежнему все писать в хранимках.

IB>Ага, и один ты, такой умный, всех раскусил..
А ты внимательно ветку почитай, и поймешь что не я один.
На форум msdn-овский зайди по этому детищу, там почитай вопросы и обсуждения.

С>>Но для работы с БД... дайте нормальный родной маппер на хп
IB>linq тебе его вполне заменит.
Да не может он мне его заменить, сколько раз повторять, потому как SingleTableInheritance support only и вообще для data-ориентированных систем.
С этого, собственно, вся ветка и началась!

С>>А так я и до этого в инете мог наковырять с десяток ORM(или назовите как хотите) выполняющих такую же лабуду.
IB>Не мог
Я не пойму, мы флудить теперь что ли будем "да-нет-нет-да"?
http://c2.com/cgi/wiki?ObjectRelationalToolComparisonDotNet

IB>В настоящее же время 90% автогенеренного линком SQL работает good enough.
Про этот good enough тоже уже неоднократно...

IB>Если тебя это так заботит, тебе ничто не мешает по прежнему все писать в хранимках.
Заботит, поэтому и продолжаю писать в них, а ты, видимо, судя по огню в глазах, кинулся уже все переписывать?

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

С>А ты внимательно ветку почитай, и поймешь что не я один.
Да, мух тоже много..

С>Да не может он мне его заменить,
Хозяин — барин, не нравится — не ешь.

С> сколько раз повторять, потому как SingleTableInheritance support only и вообще для data-ориентированных систем.
Ну это же как раз ровно то что нужно. В чем проблема-то? (Я, честно говоря, не очень понимаю, назафига вообще как-то саппортить эту самую inheritance)
Никто же не призывает его использовать там где не надо, тебе же уже писали, что границы применимости довольно очевидны.

С>С этого, собственно, вся ветка и началась!
Ну да. Ты начал плакаться что "Меня не устраивает!" и нарвался на совершенно закономерное "А чего ты хотел?".

С>Я не пойму, мы флудить теперь что ли будем "да-нет-нет-да"?
Назвался — полезай.

С>http://c2.com/cgi/wiki?ObjectRelationalToolComparisonDotNet
И какой из них встроен в язык на уровне comprehensions? Не говоря уже о том, что похожей идеологией обладает только iBATIS (отчасти), да еще BLT, которого в этом списке нет.

С>Про этот good enough тоже уже неоднократно...
Афигительный аргумент. Недовольные на ровном месте всегда найдутся, за примерами далеко ходить не надо... =)

С>Заботит, поэтому и продолжаю писать в них,
Ну и в чем тогда проблема? Линк вполне себе работает с хранимками.

С> а ты, видимо, судя по огню в глазах, кинулся уже все переписывать?
Да у меня и так все работает, чего переписывать-то? =)

С>>http://c2.com/cgi/wiki?ObjectRelationalToolComparisonDotNet
IB>И какой из них встроен в язык на уровне comprehensions? Не говоря уже о том, что похожей идеологией обладает только iBATIS (отчасти), да еще BLT, которого в этом списке нет.
Речь вообще то шла о генерации sql-кода, зачем выдергивать что то из контекста моих слов и сводить в другое русло?
А если говорить о "встроен в язык" и схожей идеологии:
В каком году вышло первое издание GoF? В каком году вообще выл впервые описан Criteria-pattern?
То что реализацию сriteria-pattern-а встроили в синтаксис языка? В этом что ли великое изобретение и заслуга?
Ну да, синтаксис более удобный, не спорю.
Просто глупо бы было если этого не сделали, т.к. тогда уж точно получилось бы то, чего уже навалом.
По понятным причинам кроме ms никто этого сделать не мог.
А кроме списка приведенного по ссылке, еще с десяток orm дополнительно наковырять можно, которые формируют запросы через criteria-паттерн (впротивоположность непроверяемым на этапе компиляции XX-QL запросам): devexpress XPO, EntitySpace, base4.net (который, кстати, якобы очень центися ms)...

IB>Афигительный аргумент. Недовольные на ровном месте всегда найдутся, за примерами далеко ходить не надо... =)
Запрос, выполняющийся в два раза медленнее из-за использования внешнего соединения вместо внутреннего, это не аргумент? Сомнительные вложенные подзапросы — тоже? Офигенно!
Нормальный t-sql разработчик может написать один и тот же запрос десятью способами, и в разных ситуациях, в зависимости от характера, объема данных оптимальный вариант может оказаться различным.
С этим ты тоже не согласен? Разве можно сказать что абсолютно всегда существует единственно правильный и оптимальный запрос? Всегда ли оптимизатор находит тот самый оптимальный план? А что делать с ora, в котором пошли по противоположному пути (не тратят особо много усилий на создание "умного" оптимизатора) и чаще используется тонкая настройка плана?

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

С>Речь вообще то шла о генерации sql-кода, зачем выдергивать что то из контекста моих слов и сводить в другое русло?
Речь шла об ORM инструменте со схожими характеристиками.

С>В каком году вышло первое издание GoF? В каком году вообще выл впервые описан Criteria-pattern?
Criteria-pattern — это не идеология. Идеология — это data-driven поход. Весь зоопарк ORM, как один, до недавнего времени плясали не от данных, а от объектов, что и являлось основным идеологическим косяком подобного рода инструментов.

С>То что реализацию сriteria-pattern-а встроили в синтаксис языка? В этом что ли великое изобретение и заслуга?
И в этом тоже.

С>Просто глупо бы было если этого не сделали, т.к. тогда уж точно получилось бы то, чего уже навалом.
То есть они таки сделали что-то особенное? Отлично, ЧТД.

С>По понятным причинам кроме ms никто этого сделать не мог.
А что мешало?

С>Запрос, выполняющийся в два раза медленнее из-за использования внешнего соединения вместо внутреннего, это не аргумент?
Кто эти "два раза" мерял, в каких условиях и на каких данных? Ты мне оба запроса покажи, план и набор данных, тогда и поговорим. Да, и эти "два раза", должны меряться не микросекундами.

С> Сомнительные вложенные подзапросы — тоже?
Они не сомнительные, они нужные.

С>Нормальный t-sql разработчик может написать один и тот же запрос десятью способами, и в разных ситуациях, в зависимости от характера, объема данных оптимальный вариант может оказаться различным.
Хорошо, что ты это понимаешь..

С>С этим ты тоже не согласен? Разве можно сказать что абсолютно всегда существует единственно правильный и оптимальный запрос? Всегда ли оптимизатор находит тот самый оптимальный план?
Ты это к чему?

С> А что делать с ora, в котором пошли по противоположному пути (не тратят особо много усилий на создание "умного" оптимизатора) и чаще используется тонкая настройка плана?
То что у оракла оптимизатор косячный — исключительно их проблемы, и даже они не очень рекомендуют пинать запрос хинтами, хотя в этом случае возможностей у оракла больше. Причины вообщем понятны, тот план который сегодня оптимальнейшим образом вылизан хинтами, после некоторого времени работы будет сливать в разы сгенеренному оптимизатором, переписывать же каждый раз руками запрос при изменении характера данных — бредовая затея. Учитесь доверять оптимизатору и правильно с ним обращаться.

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

Добрый вечер, ночь, утро, день, вечер, ...!
Попробую и я высказаться: что касается LINQ to SQL, это конечно очень удобно в коде обращаться к данным в БД. Но на мой взгляд это размазывает DAL по всем уровням, поскольку есть большой соблазн в UI, например, не парится и не обращаться к DAL, а написать код в 3 строчки, тем более что при использовании LINQ to SQL в проекте DAL может вообще не понадобится.
Лично для меня, возможно, это стало следствем моей тупости, но контроль за соединением с БД стал сущим адом, не только за соединением, но и за измененениями которые код должен внести в БД. Из-за размазывания этого DAL, никак не могу найти удобный и быстрый подход к работе с контекстом соединения (может Вы подскажите), увы сам LINQ с этим справляется не очень и приводит к трудно уловимым ошибкам (например, вдруг у контекста соединения пропадает ConnectionString, точнее становится пустой, или был доступ к связанной таблице через совойство, а потом вдруг пропал, причём с соединенем всё в норме, самое ужастное что ошибки все трудно уловимые, потому что DAL уже не принадлежит Вам, ирония судьбы )
Но и несколько слов о LINQ:
— низкая скорость работы: здесь ;
— бывают утечки памяти.

Поймите правильно, я не противник LINQ, я его использую уже давно и в серьёз, но столкнулся с рядом проблем, надеюсь Вы мне поможете их разрешить.
Всех благ!