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

__>2) разрабатывайте собственную OM based on features & tasks in DL которые вы должны реализовать

Вот только разработка собственного LINQ провайдера — та еще задачка, далеко не каждому бюджету по плечу.

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

QL>Что посоветуете в качестве альтернативы?

BLToolkit

Здравствуйте, Ночной Смотрящий, Вы писали:

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

Здравствуйте, Ночной Смотрящий, Вы писали:
НС>BLToolkit

Он вроде на основе LINQ-to-SQL сделан? Или нет?

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

__>Здравствуйте, Ночной Смотрящий, Вы писали:

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

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

Парни из SO изначально юзали Linq2SQL, а когда структура базы устаканилась и запросы стали более-менее постоянными, то написали лековыесный маппер, чтобы убрать оверхеед.
Надеяться в начале разработки на то, что сразу удастся продумать правильную структуру базы и фиксированные запросы, по меньшей мере глупо.

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

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

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

G>Парни из SO изначально юзали Linq2SQL, а когда структура базы устаканилась и запросы стали более-менее постоянными, то написали лековыесный маппер, чтобы убрать оверхеед.
И что ? Это как-то оправдывает убогость этого framework? Ваш посыл — они от него отказались, но он все равно хороший ?

G>Надеяться в начале разработки на то, что сразу удастся продумать правильную структуру базы и фиксированные запросы, по меньшей мере глупо.
По меньшей мере глупо быть дураком и не делать все правильно, в т.ч. и структуру БД и реализовать эффективные запросы. Не умеете, наймите того, кто умеет. Это же просто, следовательно правильно.

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

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

Да легко:

IQueryable<Products> x(IQueryable<Products> q, bool f)
{
     return f ? q.Where(p => p.UnitsInStock > 0) : q.Where(p => p.OrderLines.Sum(x => x.Price * x.Quantity) > 1000);     
}

Покажи как такое с голым sql сделать.


G>>Парни из SO изначально юзали Linq2SQL, а когда структура базы устаканилась и запросы стали более-менее постоянными, то написали лековыесный маппер, чтобы убрать оверхеед.
__>И что ? Это как-то оправдывает убогость этого framework? Ваш посыл — они от него отказались, но он все равно хороший ?
Важно что они с него начали и 2 года на нем прожили. Если бы они начали с написания своего маппера, то скорее всего мы бы сейчас не знали про SO.
Считаешь это недостаточная причина использовать в своих проектах Linq2ORM? Ведь многие проекты даже до тысячной части нагрузки SO не доживают.

G>>Надеяться в начале разработки на то, что сразу удастся продумать правильную структуру базы и фиксированные запросы, по меньшей мере глупо.
__>По меньшей мере глупо быть дураком и не делать все правильно, в т.ч. и структуру БД и реализовать эффективные запросы. Не умеете, наймите того, кто умеет. Это же просто, следовательно правильно.
Тут не вопрос в умении, а вопрос в знании. Заранее никто не знает что понадобится. Даже самые тяжелые методологии не помогают избежать изменений.

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

QL>Здравствуйте, Ночной Смотрящий, Вы писали:
НС>>BLToolkit
QL>Он вроде на основе LINQ-to-SQL сделан? Или нет?
BLToolkit — самостоятельный продукт.

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

__>Перефразируя классика скажу что "слухи о " полезности LINQ провайдера "сильно преувеличены"

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

__>. Я например всегда обходился SQL

А некоторые так вообще голым ассемблером обходились. Это что, аргумент что ли?

__>Парни из stack_overflow тоже похоже с этим не парились когда разрабатывали dapper

Dapper это не ORM. Задачи работы с декларативными запросами и меппера в общем случае непересекающиеся. Т.е. можно использовать LINQ и не использвать меппер, и наоборот.

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

QL>Он вроде на основе LINQ-to-SQL сделан? Или нет?

Нет.

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

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

G>Да легко:

G>

G>IQueryable<Products> x(IQueryable<Products> q, bool f)
G>{
G>     return f ? q.Where(p => p.UnitsInStock > 0) : q.Where(p => p.OrderLines.Sum(x => x.Price * x.Quantity) > 1000);     
G>}
G>

G>Покажи как такое с голым sql сделать.

Извиняюсь, тут разве не 2 разных LINQ запроса?

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

V>Извиняюсь, тут разве не 2 разных LINQ запроса?
Суть и мощь совсем не в том. Вот пример возможно более наглядный: ORM vs Plain SQL: по просьбам трудящихся

Автор: IT
Дата: 15.09.12

.

Здравствуйте, Ночной Смотрящий, Вы писали:

НС>BLToolkit
Если уж сравнивать легковесный ОРМ с монстром типа EF: как принято выкручиваться с самым простым UI типа "выгреб — прибиндил — отредактировал — сохранил"?

В BLToolkit ведь нет ChangeTracking/ChangeContext-а?

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

S>Если уж сравнивать легковесный ОРМ с монстром типа EF: как принято выкручиваться с самым простым UI типа "выгреб — прибиндил — отредактировал — сохранил"?

EditableObject BLT поддерживает (старая его часть), а всякие lazy loading и identity tracking — весьма спорные технологии. Лично я с удовольствием обхожусь без них при возможности.

S>В BLToolkit ведь нет ChangeTracking/ChangeContext-а?

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

Здравствуйте, Ночной Смотрящий, Вы писали:

НС>EditableObject BLT поддерживает (старая его часть), а всякие lazy loading и identity tracking — весьма спорные технологии. Лично я с удовольствием обхожусь без них при возможности.
Это не всегда удобно

Самый простой пример — Master-Detail.
Сценарий 1:
Прибиндили на форму с гридом, добавили записи

Сценарий 2:
Передали мастера в метод для заполнения по какому-то шаблону, записи в спецификации удалились/поменялись

Как сохранять изменения в БД? Или имеем промежуточный слой, который отслеживает изменения и прозрачен для БЛ, или нагружаем ответственностью за отслеживание все части приложения.

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

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

S>Как сохранять изменения в БД?

Отдельный фреймворком, если очень хочется именно такой сценарий. Накапливаем данные в биндинге (иными словами, в UI), на основании накопленных данных и метаданных формируем сразу апдейт или набор DTO для пересылки изменений. При этом, к примеру, появляется возможность оформленные в UI как групповые операции групповыми же выполнять и в БД (скажем, если я жму кнопку "Удалить все", то в БД идет DELETE FROM OrderLine WHERE Order.ID=123, а не куча DELETE FROM OrderLine WHERE ID=XXX).

S> Или имеем промежуточный слой, который отслеживает изменения и прозрачен для БЛ, или нагружаем ответственностью за отслеживание все части приложения.

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

S>Достаточно попросить многозвенку

Многозвенка тут ничего не меняет.

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

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

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

G>>Да легко:

G>>

G>>IQueryable<Products> x(IQueryable<Products> q, bool f)
G>>{
G>>     return f ? q.Where(p => p.UnitsInStock > 0) : q.Where(p => p.OrderLines.Sum(x => x.Price * x.Quantity) > 1000);     
G>>}
G>>

G>>Покажи как такое с голым sql сделать.

V>Извиняюсь, тут разве не 2 разных LINQ запроса?

Да хоть 10. Как мне сделать в SQL функцию с подобным поведением.

Потому что все сложные запросы в Linq у меня генеряться по частям. Вот одна из таких частей.

Здравствуйте, 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)

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

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

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

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

Здравствуйте, Ночной Смотрящий, Вы писали:

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

НС>А некоторые так вообще голым ассемблером обходились. Это что, аргумент что ли?
Для дураков, которые не знают SQL и вынуждены пользоваться индейскими костылями конечно не аргумент. Для меня аргумент.

Здравствуйте, gandjustas, Вы писали:
G>Потому что все сложные запросы в Linq у меня генеряться по частям. Вот одна из таких частей.
Самым главным преимуществом Linq перед Pure SQL для меня является повторное использование кода, т.к. перенос бизнес логики в SQL для меня всегда сопровождался с кромешной копипастой