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

G>>Если ты не видишь полезности в Linq to database, то это не значит что другие не видят.
__>Разве я против? Я же написал "на вкус и цвет товарищей нет".

>>Я с линком писал такие запросы, что вручную их почти нереально было родить. И эти запросы проверялись при компиляции.
__>Чушь. Ну напишите мне что я "нереально не могу родить" с помощью T-SQL или PL/SQL, что вы можете сделать с помощью LINQ.

Начнём с совcем классики. E2, так сказать:

 db.Table.Where(t => (filter1 == null || t.Field1 == filter1) && (filter2 == null || t.Field2 == filter2)  && (filter3 == null || t.Field3 == filter3));

Incorrect syntax near ') динамический sql не предлагать.

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

Y>Начнём с совcем классики. E2, так сказать:
Y>

 db.Table.Where(t => (filter1 == null || t.Field1 == filter1) && (filter2 == null || t.Field2 == filter2)  && (filter3 == null || t.Field3 == filter3));

Y>Incorrect syntax near ') динамический sql не предлагать.

declare @filter1 varchar(max)
set @filter1 = 'body'
declare @filter2 varchar(max)
--set @filter2 = '1'
select * from settings 
where (@filter1 IS NULL OR [Key] = @filter1) AND (@filter2 IS NULL OR [Value] = @filter2)

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

Y>Начнём с совcем классики. E2, так сказать:

Y>

 db.Table.Where(t => (filter1 == null || t.Field1 == filter1) && (filter2 == null || t.Field2 == filter2)  && (filter3 == null || t.Field3 == filter3));

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

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

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

G>>Покажи как такое с голым sql сделать.
__>if (f)
__>

__>select ... from [Table or Join] where [...].UnitsInStock>0
__>

__>else
__>

__>select ... from [Table or Join] group by ... having sum([...].Price * [...].Quantity) > 1000)
__>

__>Смотрите. И что по вашему прозрачнее?

Неверно, какой IQueryable на входи подается — неизвестно, там уже могут быть join и фильтры, на результат также могу быть навешаны дополнительные предикаты.

Во вторых твой код тупо длиннее.

В третьих — код не рабочий, так как превратить три точки в что-то конкретное далеко не тривиально.



G>>Важно что они с него начали и 2 года на нем прожили. Если бы они начали с написания своего маппера, то скорее всего мы бы сейчас не знали про SO.
__>Не уверен что это эта тормозная и глючная штука была причиной роста SO. Предположения того что ЭТО увеличивает скорость разработки неверны. Просто на тот момент это казалось модным
Я тоже не уверен что она была причиной роста. Но ручное написание запросов однозначно стало бы причиной фейла.
И таки да — увеличивает скорость разработки в разы. Тупо за счет compile-time check.



G>>Считаешь это недостаточная причина использовать в своих проектах Linq2ORM? Ведь многие проекты даже до тысячной части нагрузки SO не доживают.
__>Я считаю это бессмысленным, т.к. это framework не имеет никаких преимуществ перед обычным Data FCL .Net
Как минимум compile time check. Этого уже более чем достаточно, чтобы писать быстрее, чем sql запросы в тексте.


G>>Тут не вопрос в умении, а вопрос в знании. Заранее никто не знает что понадобится. Даже самые тяжелые методологии не помогают избежать изменений.
__>Я что не понимаю в какую сторону вы клоните (клонитесь?). Если мне нужно использовать database в проекте я точно знаю, ЧТО мне понадобится и каким образом я буду это реализовать. Does it make sense?
В любом случае ты в начале проекта не сможешь родить схему и все запросы, чтобы они ни разу не изменились.

Здравствуйте, Ringin, Вы писали:
R>Выскажите пожалуйста свои мнения!

Здесь достаточно интересный проект...

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

G>Неверно, какой IQueryable на входи подается — неизвестно, там уже могут быть join и фильтры, на результат также могу быть навешаны дополнительные предикаты.
G>Во вторых твой код тупо длиннее.
G>В третьих — код не рабочий, так как превратить три точки в что-то конкретное далеко не тривиально.
У меня твердое ощущение, что вы человек исключительно гуманитарного склада ума. Причем в крайней степени (стадии?). По пунктам:
1) Да все равно мне какой IQueryable на вход подается. Вы можете все что угодно там джойнить и выставлять любые SARG во клиентском коде (в N строках кода) — я все равно сделаю все лакончинее и эффективнее Одним запросом
2) Вы рассчитывайте по SARG и все встанет на свои места. Если вы знаете, что такое SARG конечно . Это не говоря уже о сравнении с итоговым SQL то EF.
3) Да что вы такое говорите ? Не собирается в студии ? Вы привели мне пример концептуального кода, я привел вам контрпример. Зачем глупости-то говорить?

G>И таки да — увеличивает скорость разработки в разы. Тупо за счет compile-time check.
Это называется школярское мышление. Вы видимо не можете себе представить, насколько может быть производительным инженер, если он владеет предметной областью.
compile-time check — это суррогат малограмотных идиотов, которые из-за отсутствия системного мышления пересобирают проект каждые 5 секунд в поисках ошибки.

G>Как минимум compile time check. Этого уже более чем достаточно, чтобы писать быстрее, чем sql запросы в тексте.
Для разработки sql-запросов существуют специальные tools, которые позволяют делать это быстро, эффективно и тут реализовать проверки with sql engine. Если вы владеете подобными tools и имеете соответствующий опыт разработки SQL, то вы будете делать это гораздо быстрее чем с помощью какого-то индо-пакистанского костыльного убожества.

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

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

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

G>>Неверно, какой IQueryable на входи подается — неизвестно, там уже могут быть join и фильтры, на результат также могу быть навешаны дополнительные предикаты.
G>>Во вторых твой код тупо длиннее.
G>>В третьих — код не рабочий, так как превратить три точки в что-то конкретное далеко не тривиально.
__>У меня твердое ощущение, что вы человек исключительно гуманитарного склада ума. Причем в крайней степени (стадии?).
Да, я понимаю то когда нечего ответить, то можно поискать проблемы в собеседнике.

__>По пунктам:
__>1) Да все равно мне какой IQueryable на вход подается. Вы можете все что угодно там джойнить и выставлять любые SARG во клиентском коде (в N строках кода) — я все равно сделаю все лакончинее и эффективнее Одним запросом

Давай вариант попроще:

if(value1 != null)
{
    query = query.Where( e => e.Field1 == value1 )
}

if(value2 != null)
{
    query = query.Where( e => e.Field2 == value2 )
}

if(value3 != null)
{
    query = query.Where( e => e.Field3 == value3 )
}

Количество вариантов запросов на выходе — 6 штук. Вообще если у тебя N то запросов будет N! (факториал).
При этом при изменении одного аспекта тебе надо будет вносить правки в (N-1)! запросов.

При N=5 человек уже не может это делать.


__>2) Вы рассчитывайте по SARG и все встанет на свои места. Если вы знаете, что такое SARG конечно . Это не говоря уже о сравнении с итоговым SQL то EF.
Понятия не имею что такое SARG. Гугл не помог. Скорее всего ты привел эти буквы чтобы казаться умнее. Может ты расскажешь что это?


__>3) Да что вы такое говорите ? Не собирается в студии ? Вы привели мне пример концептуального кода, я привел вам контрпример. Зачем глупости-то говорить?
Мой пример собирается в студии, я только оттуда несущественные детали убрал. Ты же пропустил довольно важные части.

G>>И таки да — увеличивает скорость разработки в разы. Тупо за счет compile-time check.
__>Это называется школярское мышление. Вы видимо не можете себе представить, насколько может быть производительным инженер, если он владеет предметной областью.
Это не релевантно, независимо от знания предметной области проверка кода компилятором ускоряет разработку.


__>compile-time check — это суррогат малограмотных идиотов, которые из-за отсутствия системного мышления пересобирают проект каждые 5 секунд в поисках ошибки.
Зачем пересобирать? Студия прямо при вводе показывает несоответствия типов \ опечатки. Причем именно банальные опечатки \ недоисправления после копипасты приводят к большей части ошибок, которые в случае текстового SQL отлавливаются очень сложно.

G>>Как минимум compile time check. Этого уже более чем достаточно, чтобы писать быстрее, чем sql запросы в тексте.
__>Для разработки sql-запросов существуют специальные tools, которые позволяют делать это быстро, эффективно и тут реализовать проверки with sql engine. Если вы владеете подобными tools и имеете соответствующий опыт разработки SQL, то вы будете делать это гораздо быстрее чем с помощью какого-то индо-пакистанского костыльного убожества.
Пример? Что ты используешь?

G>>В любом случае ты в начале проекта не сможешь родить схему и все запросы, чтобы они ни разу не изменились.
__>А мне и не нужно этого делать. Я достаточно владею SQL, чтобы гибко изменять код и схему в зависимости от измени внутри проекта. Зачем мне для этого этот тормозной костыльный каркас?
Каждое изменение текстового SQL имеет вероятность ошибки. Отсутствие декомпозиции запросов повышает риск получения несогласованных действий.

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

НС>>Сказать ты можешь что угодно, но по факту наличие возможности статического контроля запросов компилятором и развитые средства декомпозиции дают вполне неиллюзорные бенефиты. Чтобы от этих бенефитов отказываться нужны железобетонные аргументы.
__>Какие аргументы

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

__>Я могу выполнить любой запрос с использованием SqlDataReader в несколько раз быстрее

Ну попробуй, обгони BLT. Результаты объективных замеров показывают, что рукопашный код быстрее больше чем на единицы процентов написать не удается.

__>, при этом мой код будет проще, яснее и легче в отладке.

Ручное чтение из ридела vs linq запрос? Ну ну.

__>Для дураков, которые не знают SQL и вынуждены пользоваться индейскими костылями конечно не аргумент. Для меня аргумент.

При чем тут знание SQL? Линк предназначен вовсе не для тех, кто не знает SQL.

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

QL>Здесь достаточно интересный проект...

At this moment, and as far as we know, there's no commercial or open source ORM mapper with a full Linq provider apart from Microsoft, LLBLGen and Signum Framework.

Дальше читать не стал.

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

__>Перефразируя классика скажу что "слухи о " полезности LINQ провайдера "сильно преувеличены". Я например всегда обходился SQL, там где теоретически возможно использовать LINQ — это было более просто, изящнее и гораздо эффективнее. Парни из stack_overflow тоже похоже с этим не парились когда разрабатывали dapper. Хотя на вкус и цвет товарищей. Пусть те кто хотят использовать технологии MS типа LINQ, "подставляют бокалы, кто пьет такое".

У SQL как у одной из технологий широко используемых сегодня при разработке современных приложений есть одна большая фундаментальная проблема — отсутствие внятной интеграции с языками, которые этот SQL используют. Например, полное отсутсвие типизации, необходимость писать дополнительные слои, для перевода SQL в термины приложения. В результате SQL начинает потихоньку выпадать из технического прогресса и становиться откровенным тормозом. Например, словосочетание "рефакторинг базы данных" для большинства на сегодня фантастика.

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

Ближе всего, на мой нескромный взгляд, к решению типизированного SQL подошёл BLToolkit. Ещё ближе подойдёт linq2db. Но решение близкое к идеальному возможно только на специально обученном DSL.

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

>>Я с линком писал такие запросы, что вручную их почти нереально было родить. И эти запросы проверялись при компиляции.
__>Чушь. Ну напишите мне что я "нереально не могу родить" с помощью T-SQL или PL/SQL, что вы можете сделать с помощью LINQ.

Вопрос не в теоретической возможности, а в практической реальности. Ты просто не станешь писать на SQL то, что можно сделать с помощью LINQ. Если ты, конечно, вменяемый разработчик.

Реально сложные запросы на LINQ пишутся как правило в несколько выражений, позволяющих конструировать запрос пошагово. Для plain SQL это делается только с помощью конкатенации строк, что само по себе было проклято ещё теми, кто придумал DAL. Конкатенация/конструирование сложного запроса в LINQ это зачастую даже более предпочтительно, чем написать целый запрос целиком, потому что это более читаемо.

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

S>Достаточно попросить многозвенку, или возможность добавлять записи в нескольких потоков и придётся писать всё, что умеет орм, только ручками.

Зачем же? T4 в руки и всё захреначим синей изолентой.

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

__>1) Да все равно мне какой IQueryable на вход подается. Вы можете все что угодно там джойнить и выставлять любые SARG во клиентском коде (в N строках кода) — я все равно сделаю все лакончинее и эффективнее Одним запросом

Только при этом задолбаешься пот с лица вытирать.

__>2)Если вы знаете, что такое SARG конечно .

Shelter Animals Rescue Group?

G>>И таки да — увеличивает скорость разработки в разы. Тупо за счет compile-time check.
__>Это называется школярское мышление. Вы видимо не можете себе представить, насколько может быть производительным инженер, если он владеет предметной областью.
__>compile-time check — это суррогат малограмотных идиотов, которые из-за отсутствия системного мышления пересобирают проект каждые 5 секунд в поисках ошибки.

Таак, пошёл неадекват. Вот оказывается какие они инженеры, владеющие предметной областью.

G>>Как минимум compile time check. Этого уже более чем достаточно, чтобы писать быстрее, чем sql запросы в тексте.
__>Для разработки sql-запросов существуют специальные tools, которые позволяют делать это быстро, эффективно и тут реализовать проверки with sql engine.

Ну-ка, назови ка нам, SQL разработчикам с пятидесятилетным стажем хоть один SQL тул, чтобы мы не поржали хотя бы 10 минут.

G>>В любом случае ты в начале проекта не сможешь родить схему и все запросы, чтобы они ни разу не изменились.
__>А мне и не нужно этого делать. Я достаточно владею SQL, чтобы гибко изменять код и схему в зависимости от измени внутри проекта. Зачем мне для этого этот тормозной костыльный каркас?

Тебе стоит поделится своей технологий разработки с общественностью. Если всё так как ты рассказываешь, то номинирование на Нобелевку гарантирую.

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

IT>Ближе всего, на мой нескромный взгляд, к решению типизированного SQL подошёл BLToolkit. Ещё ближе подойдёт linq2db. Но решение близкое к идеальному возможно только на специально обученном DSL.
Кстати, linq2db теперь полностью на C#? Так и дальше будет?

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

Y>>Начнём с совcем классики. E2, так сказать:
Y>>

 db.Table.Where(t => (filter1 == null || t.Field1 == filter1) && (filter2 == null || t.Field2 == filter2)  && (filter3 == null || t.Field3 == filter3));

Y>>Incorrect syntax near ') динамический sql не предлагать.

__>

__>declare @filter1 varchar(max)
__>set @filter1 = 'body'
__>declare @filter2 varchar(max)
__>--set @filter2 = '1'
__>select * from settings 
__>where (@filter1 IS NULL OR [Key] = @filter1) AND (@filter2 IS NULL OR [Value] = @filter2)
__>

Только у вас получился совсем другой запрос с совсем другим планом.

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

G>А ты когда на него смотрел последний раз?
Месяц назад, примерно. Как был недоделком, так и остался.

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

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

G>>А ты когда на него смотрел последний раз?
IB>Месяц назад, примерно. Как был недоделком, так и остался.

Точно? То что ты описываешь было актуально около 2 лет назад.

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

F>Кстати, linq2db теперь полностью на C#? Так и дальше будет?

Пока других планов нет.

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

F>>Кстати, linq2db теперь полностью на C#? Так и дальше будет?
IT>Пока других планов нет.
Это хорошо.

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

IT>Только при этом задолбаешься пот с лица вытирать.
Зато это работает. Быстро. Для этого и нужен мозг вы не находите ?

IT>Shelter Animals Rescue Group?
В точку! Именно так! Как вы догадались? Как я сам ранее не догадался???

IT>Таак, пошёл неадекват. Вот оказывается какие они инженеры, владеющие предметной областью.
А что вас смущает? Или вы удивлены тем что есть еще люди, за которых VS не думает ?

IT>Ну-ка, назови ка нам, SQL разработчикам с пятидесятилетным стажем хоть один SQL тул, чтобы мы не поржали хотя бы 10 минут.
Да мы сами с усами вообще-то .
1) Для Sql Server я использую Query Analyzer если это возможно. Ну и SSMS, когда приходится.
2) Для Oracle Sql*Plus & Oracle SQL Developer
Начинайте ржать (кукарекать я думаю необязательно)

IT>Тебе стоит поделится своей технологий разработки с общественностью. Если всё так как ты рассказываешь, то номинирование на Нобелевку гарантирую.
По шагам сложно, но я попробую. Нужно например расширить таблицу, я исполняю ALTER TABLE. Нужно добавить логику в sp — аналогично меняю sp. Требуется поменять код в соответствии с DL — меняю. Это называется — разработка программного обеспечения. Слышали про такой термин?
Это кстати просто — на нобелевскую премию ну никак не тянет.