Здравствуйте, IB, Вы писали:
IB>Здравствуйте, Enomay, Вы писали:
E>>можно их список? IB>краце, POCO на самом деле нефига не POCO,
Configuration.ProxyCreationEnabled = false;
IB>LazyLoading хрен отключишь
Configuration.LazyLoadingEnabled = false;
IB>Linq провайдер мало того что неполноценный и половину нормальных запросов не поддерживает, так еще и запросы генерит хуже чем старый-добрый Linq2SQL.
Тут вроди тоже стало немного лучше, но в таки он кривоват .
IB>И, самое главное, корень всех этих проблем в том, что идеологически он так и остался монструозным Full Blown ORM, непонятно для каких задач предназначенным, который внутри себя строит некоторую абстрактную модель и всю работу делает через нее.
Сейчас наружу торчит простой и совсем не монструозный API, которого достаточно для решения 80% типичных задач.
E>>сейчас выбираю между им и не им, и было бы очень интересно услышать аргументы... IB>его не советую.
Не фонтан конечно, но альтернатив не особо. Из плюсов — ет мейнстрим и почти любая проблема гуглится за 5 минут.
Здравствуйте, hardcase, Вы писали:
НС>>Так я и не предлагаю ее проверять. Просто без такой проверки ПМ из мегавещи превращается во вполне обыденный синтаксический сахарок. H>Тем не менее он очень неслабо сокращает количество говнокода.
Я бы даже сказал, что разницы практически нет.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, Enomay, Вы писали:
E>в каком смысле? имется в виду что он возвращает класс наследник от POCO?
Да, плюс есть ограничения на вид самого класса.
E>я его не трогал, но у меня по умолчанию он не работает.
Работает в полный рост. Да, еще дополнительные классы со всякой обвязкой.
E>в каком смысле не полноценный? слишком извращенных запросов не писал, но интерестно, с чем возможно придется столкнуться.
Там особых извращений и не надо, шаг в сторону и "не могу построить запрос, проблемы с моделью"
E>я смотрел местами он запросы генерирует лучше чем linq2sql.
То что я смотрел — хуже, проверял по планам. С банальной связкой родитель-потомки не справился — это клиника.
E>но хорошо это или плохо отдельный вопрос.
Это прекрасно.
E>а что советуете?
Linq2SQL, ну или BLT.
E>на данный момент интересует поддержка mssql с дальнейшим переходом на postgress/mysql.
Тогда лучше BLT, так как L2S держит только MSSQL
E>я склоняюсь в сторону NHibernate.
Та же хрень, что и EF, только в профиль.
Здравствуйте, itslave, Вы писали:
IB>>краце, POCO на самом деле нефига не POCO, I>
I>Configuration.ProxyCreationEnabled = false;
I>
IB>>LazyLoading хрен отключишь I>
I>Configuration.LazyLoadingEnabled = false;
I>
Хрен там, это только чуть лучше маскирует то что там в реальности происходит, проблемы никуда не деваются.
I>Тут вроди тоже стало немного лучше, но в таки он кривоват .
Не стало.
I>Сейчас наружу торчит простой и совсем не монструозный API,
Через этот API все равно потроха в разные стороны торчат и этот API на каждом шагу исключения кидает, так как внутренний сложный механизм с его простотой почему-то не справляется.
I>которого достаточно для решения 80% типичных задач.
Для решения 90% типичных задач достаточно Linq2SQL, так какого хрена?
I>Не фонтан конечно, но альтернатив не особо.
Linq2SQL, BLT.
I> Из плюсов — ет мейнстрим и почти любая проблема гуглится за 5 минут.
Категорически не интересно ходить по граблям, даже если по ним уже прошли миллионы леммингов, если можно по ним не ходить.
IB>Хрен там, это только чуть лучше маскирует то что там в реальности происходит, проблемы никуда не деваются.
Конкретно это работает: не генерирует прокси и LazyLoading отрубается.
I>>Тут вроди тоже стало немного лучше, но в таки он кривоват . IB>Не стало.
Перфоманс они подтянули прилично. Прекомпиляцию запросов добавили. навскидку не помню, полезли ли они в linq2EF, но у меня после миграции стало работать ощутимо быстрее.
I>>Сейчас наружу торчит простой и совсем не монструозный API, IB>Через этот API все равно потроха в разные стороны торчат и этот API на каждом шагу исключения кидает, так как внутренний сложный механизм с его простотой почему-то не справляется.
Не без греха, но исключения у меня почему то 'на каждом шагу' не кидает.
I>>которого достаточно для решения 80% типичных задач. IB>Для решения 90% типичных задач достаточно Linq2SQL, так какого хрена?
Потому как не recommended way. С массой ограничений, и без перспектив развития.
I>>Не фонтан конечно, но альтернатив не особо. IB>Linq2SQL, BLT.
В сухом остатке остается BLT. Ожидаемое мнение от автора BLT.
I>> Из плюсов — ет мейнстрим и почти любая проблема гуглится за 5 минут. IB>Категорически не интересно ходить по граблям, даже если по ним уже прошли миллионы леммингов, если можно по ним не ходить.
Миллионы леммингов не могут ошибаться(с)
На самом деле, не так страшен черт как его малюют.
Здравствуйте, itslave, Вы писали:
I>Конкретно это работает: не генерирует прокси и LazyLoading отрубается.
О да! LL очень красиво отрубается, и вообще ничего не загружает. Прокси может и не генерятся, но с произвольным объектом все равно работать нельзя.
I>Перфоманс они подтянули прилично. Прекомпиляцию запросов добавили.
Толку от этого, если запросы все равно строятся хуже чем в L2S?
I>Не без греха, но исключения у меня почему то 'на каждом шагу' не кидает.
А у меня кидает даже на самых примитивных сценариях, типа group join-а.
I>Потому как не recommended way.
Who cares? И, главное, кем не recommended? Теми кто EF разрабатывает? Люди, которые за десяток лет не смогли создать нормальный рабочий продукт, не имеют права что-либо кому-либо рекомендовать.
I> С массой ограничений, и без перспектив развития.
С перспективами развития все понятно, а вот с органичениями пожалуйста по подробнее.
По факту, мы уже много лет с успехом пользуемся L2S и с особыми ограничениями не сталкивались. Прелесть в том, что L2S штука очень простая, легковесная и именно ограничений он не накладывает вообще никаких. Он много чего не может (к счастию), но это не проблема, так как все это спокойно дописыватеся рядом и объем этого дописывания достаточно смешной.
А вот EF, в силу своей врожденной кривизны, как раз и накладывает очень большое количество совершенно необязательных ограничений.
Так повторяю свой вопрос — какого хрена?
I>На самом деле, не так страшен черт как его малюют.
Он не страшен, он убог и уродлив.
Здравствуйте, IB, Вы писали:
I>>LL очень красиво отрубается, и вообще ничего не загружает.
Загружает все что скажешь ему загрузить. там есть специальный extension method — Include и специальное понятие — navigation property. И все загружается.
IB>но с произвольным объектом все равно работать нельзя.
Можно пример "произвольного объекта", с которым оно не работает? У меня работает с самописными POCO обьектами аж бегом.
IB>Толку от этого, если запросы все равно строятся хуже чем в L2S?
Толку то, что стало работать быстрей. Если уж совсем все печально, то есть воркэраунды. Костыли, согласен, но они далеко не каждый день нужны.
I>>Не без греха, но исключения у меня почему то 'на каждом шагу' не кидает. IB>А у меня кидает даже на самых примитивных сценариях, типа group join-а. http://msdn.microsoft.com/en-us/library/bb397895.aspx
Ничего не кидает.
I>>Потому как не recommended way. IB>Who cares? И, главное, кем не recommended? Теми кто EF разрабатывает? Люди, которые за десяток лет не смогли создать нормальный рабочий продукт, не имеют права что-либо кому-либо рекомендовать.
Очевидно не рекомендуется теми, кто бюджеты и прочие ресурсы распределяет.
IB>С перспективами развития все понятно, а вот с органичениями пожалуйста по подробнее.
Сходу — провайдеры к разным СУБД.
IB>А вот EF, в силу своей врожденной кривизны, как раз и накладывает очень большое количество совершенно необязательных ограничений. IB>Так повторяю свой вопрос — какого хрена?
Пока что ограничения больше декларируемые чем реальные. И акцент на "неправильной" архитектуре, чем на реальных юзкейсах. Мир несовершенен, селяви.
I>>На самом деле, не так страшен черт как его малюют. IB>Он не страшен, он убог и уродлив.
Ты необьективен.
Здравствуйте, itslave, Вы писали:
I>Загружает все что скажешь ему загрузить. там есть специальный extension method — Include и специальное понятие — navigation property. И все загружается.
Ну и какое отсутствие ограничений с extension method-ом и какой POCO с navigation property? Нафига все это надо, если можно (и нужно) обходиться обычным linq запросом? Это называется "мы придумали афигенские подпорки к нашим прекрасным костылям" (с)
I>Толку то, что стало работать быстрей.
Пойми — тормоза маппинга, это другой порядок малости по сравнению с тормозами от неэффективного SQL запроса. Так что нет — быстрее не стало.
I>Если уж совсем все печально, то есть воркэраунды. Костыли, согласен, но они далеко не каждый день нужны.
Ровно все тот же вопрос — задлянафига все это, если можно туда вообще не наступать?
I>http://msdn.microsoft.com/en-us/library/bb397895.aspx I>Ничего не кидает.
Объясни это моему эксепшену. Ты left join и group join не перепутал?
I>Очевидно не рекомендуется теми, кто бюджеты и прочие ресурсы распределяет.
Тут, понимаешь, есть такой момент, очень показательный. По факту, "не рекомендованный" L2S написанный за год и положенный на полку уже года 3, по прежнему эффективнее, функциональнее и, как следствие, полезнее в реальных практических задачах, чем "рекомендованный" EF, общая история которого насчитывает лет десять и в который по прежнему вкладывают ресурсы.
Что довольно однозначно говорит как о ресурсах, так и о тех кто их распределяет.
I>Сходу — провайдеры к разным СУБД.
Это не ограничения, это просто всем кроме сиквела не повезло.
I>Пока что ограничения больше декларируемые чем реальные.
Неэффективные запросы и невозможность нормальным образом эти запросы формировать — это очень реальные ограничения, с которыми лично я мириться не собираюсь, не говоря уже об ограничениях на мои объекты.
А вот возражения против L2S которые заключаются в том, что он "не рекомендован" смотрятся действительно довольно забавно.
I>И акцент на "неправильной" архитектуре, чем на реальных юзкейсах.
Акцент как раз на реальных юзкейсах, неприменимость в которых EF, явилась следствием кривой EF-овой архитектуры, что очень хорошо видно. Просто очень наглядный пример, к каким последствиям может привести кривая архитектура и упертость в идеологию, так что грех было не упомянуть.
I>Ты необьективен.
Я более чем объективен. Я честно потратил кучу времени пытаясь оценить полезность перехода наших продуктов с L2S на EF. Не абстрактных юзкейсов, а вполне реальных продуктов с реальными сценариями, как уже написанных, так и находящихся в стадии проектирования. Я ооочень надеялся, что из него все-таки получилось хоть что-то приличное... Однако вывод для EF весьма не утешителен — L2S до сих пор уделывает его, по удобству и эффективности, как гайдар плохиша. Причем разочарование мое этим убожеством столь велико, что у меня до сих пор цензурных слов не очень много находится, как можно заметить.
Необъективен тут скорее ты, так как, похоже, сидишь на EF уже довольно плотно и оправдываешь себя отсутствием альтернатив.
Здравствуйте, IB, Вы писали:
IB>Здравствуйте, itslave, Вы писали:
I>>Загружает все что скажешь ему загрузить. там есть специальный extension method — Include и специальное понятие — navigation property. И все загружается. IB>Ну и какое отсутствие ограничений с extension method-ом и какой POCO с navigation property? Нафига все это надо, если можно (и нужно) обходиться обычным linq запросом? Это называется "мы придумали афигенские подпорки к нашим прекрасным костылям" (с)
У тебя каждый раз новые претензии. Сначала lazy loading не отключался, оказалось что отключается. Затем "а если отключается то ничего не грузит". Теперь оказывается грузит, но не так как тебе хотелось бы. Определись как нить, в чем собственно говоря претензии. Индусами написано? Ну и примера POCO, с которым "не работает" EF я наверно не дождусь.
Ну и кстате считаю навигации удобной фичей. Просто, ясно и декларативно указал что надо загружать, одним запросом вытянул целый граф объектов и делай с ними что хочешь.
I>>Толку то, что стало работать быстрей. IB>Пойми — тормоза маппинга, это другой порядок малости по сравнению с тормозами от неэффективного SQL запроса. Так что нет — быстрее не стало.
Я про маппинг нигде ни слова не говорил. Я говорил про кеширование linq-запросов, т.е. sql-запрос не строится каждый раз из linq. На простых сценариях(много одинаковых простых запросов с разными параметрами) у меня перфоманс вырос в 2 раза. Там история просто писец. Сначала они разводили руками и говорили "ой". Затем придумали воркэраунд, типа вручную прекомпилируйте и будет вам счастье. Затем в новой версии похерили. Теперь от обратно сделали. Дурдом блин
I>>Если уж совсем все печально, то есть воркэраунды. Костыли, согласен, но они далеко не каждый день нужны. IB>Ровно все тот же вопрос — задлянафига все это, если можно туда вообще не наступать?
А затем что "яка розумная цьому альтернатыва", как говоривал украинский классик. По сути — только BLToolkit. Но если коснуться маркетинга, саппорта и т.д. — то увы, тут все очень грустно. В смысле надоест тебе его развивать или уедешь ты в отпуск на 3 месяца — и усе. Ни саппорта ни фикса критических багов. опять таки комьюнити, в разы меньше.
I>>http://msdn.microsoft.com/en-us/library/bb397895.aspx I>>Ничего не кидает. IB>Объясни это моему эксепшену. Ты left join и group join не перепутал?
Может и пуьаю, давай свой пример, посмотрим.
I>>Очевидно не рекомендуется теми, кто бюджеты и прочие ресурсы распределяет. IB>Тут, понимаешь, есть такой момент, очень показательный. По факту, "не рекомендованный" L2S написанный за год и положенный на полку уже года 3, по прежнему эффективнее, функциональнее и, как следствие, полезнее в реальных практических задачах, чем "рекомендованный" EF, общая история которого насчитывает лет десять и в который по прежнему вкладывают ресурсы. IB>Что довольно однозначно говорит как о ресурсах, так и о тех кто их распределяет.
Но у этих людей власть.
I>>Сходу — провайдеры к разным СУБД. IB>Это не ограничения, это просто всем кроме сиквела не повезло.
На этом можно и закончить о недостатках l2s.
I>>Пока что ограничения больше декларируемые чем реальные. IB>Неэффективные запросы и невозможность нормальным образом эти запросы формировать — это очень реальные ограничения, с которыми лично я мириться не собираюсь, не говоря уже об ограничениях на мои объекты. IB>А вот возражения против L2S которые заключаются в том, что он "не рекомендован" смотрятся действительно довольно забавно.
Возражение "не мейнстрим" забавны? нуну
I>>И акцент на "неправильной" архитектуре, чем на реальных юзкейсах. IB>Акцент как раз на реальных юзкейсах, неприменимость в которых EF, явилась следствием кривой EF-овой архитектуры, что очень хорошо видно. Просто очень наглядный пример, к каким последствиям может привести кривая архитектура и упертость в идеологию, так что грех было не упомянуть.
Где реальные юзкейсы, приведи хоть один.
I>>Ты необьективен. IB>Я более чем объективен. Я честно потратил кучу времени пытаясь оценить полезность перехода наших продуктов с L2S на EF. Не абстрактных юзкейсов, а вполне реальных продуктов с реальными сценариями, как уже написанных, так и находящихся в стадии проектирования. Я ооочень надеялся, что из него все-таки получилось хоть что-то приличное... Однако вывод для EF весьма не утешителен — L2S до сих пор уделывает его, по удобству и эффективности, как гайдар плохиша. Причем разочарование мое этим убожеством столь велико, что у меня до сих пор цензурных слов не очень много находится, как можно заметить. IB>Необъективен тут скорее ты, так как, похоже, сидишь на EF уже довольно плотно и оправдываешь себя отсутствием альтернатив.
Ты сходу привел несколько вещей которые "нельзя сделать в ef". По факту оказалось что можно. Больше юзкейсов не было, только разговоры о кривизне
Здравствуйте, fddima, Вы писали:
F>Здравствуйте, itslave, Вы писали:
F>Только встретившись с EF лицом к лицу я услышал о том, что существует какая-то надуманная проблема N+1.
ты про это и это?
ну дык все ж решается с ходу прям там и написано как. И гуглится элементарно. Точно, проблема надумана.
Здравствуйте, itslave, Вы писали:
I>ну дык все ж решается с ходу прям там и написано как. И гуглится элементарно. Точно, проблема надумана.
То, что, эта проблема решается — это как раз понятно. Проблема в том, что эти проблемы сначала создаются на ровном месте, и EF этому способствует. Затем эти проблемы профилируются теми или иными инструментами. И только потом они уже они с ходу решаются.
Здравствуйте, fddima, Вы писали:
F>Здравствуйте, itslave, Вы писали:
I>>ну дык все ж решается с ходу прям там и написано как. И гуглится элементарно. Точно, проблема надумана. F> То, что, эта проблема решается — это как раз понятно. Проблема в том, что эти проблемы сначала создаются на ровном месте, и EF этому способствует. Затем эти проблемы профилируются теми или иными инструментами. И только потом они уже они с ходу решаются.
Ну кривоват, не спорю. Однако
во первых с альтернативами не густо
во вторых массовость применения фактически гарантирует то, что найденная проблема уже решена
Здравствуйте, itslave, Вы писали:
I>У тебя каждый раз новые претензии.
Нет, каждый раз одни и те же, я просто разными словами пытаюсь рассказать, чтобы таки дошло.
I>Сначала lazy loading не отключался, оказалось что отключается. Затем "а если отключается то ничего не грузит".
Я вроде бы достаточно ясно излагаю — нет? Еще раз:
LL — не отключается. Команда "LL-отключись!" по факту вовсе не означает, что можно работать так, как буд-то LL нет, она лишь означает, вместо логики LL будет кидаться исключение, но нормально работать со стандартным синтаксисом все равно нельзя.
Поэтому нет, LL — не отключается, его потроха все равно торчат и мешают работать.
Я не знаю чей больной мозг придумал такое поведение, и если ты считаешь, что это нормально, тогда понятно почему тебя устраивает EF. Плохая новость — это не нормально и так быть не должно.
I>Теперь оказывается грузит, но не так как тебе хотелось бы.
Конечно, это все к той же претензии про LL. Изобретение дополнительного синтаксиса, чтобы работать с LL и выдавать рантайм исключения при попытке воспользоваться стандартным (даже если LL формально отключен) — это и есть невозможность отключить LL и работать так, как будто его нет вообще.
I> Индусами написано? Ну и примера POCO, с которым "не работает" EF я наверно не дождусь.
Конечно не дождешься, если игнорировать будешь, я достаточно ясно написал — navigation property это не POCO.
I>Ну и кстате считаю навигации удобной фичей.
Это твои личные заблуждения.
I>Я про маппинг нигде ни слова не говорил. Я говорил про кеширование linq-запросов, т.е. sql-запрос не строится каждый раз из linq.
Твоюжмать. Что в лоб, что полбу. Еще раз: тормоза на построении запроса и получении результата обратно — это другой порядок малости, по сравнению с тормозами от не эффективного SQL-я.
I>На простых сценариях(много одинаковых простых запросов с разными параметрами) у меня перфоманс вырос в 2 раза.
Это говорит лишь о том, что они и здесь умудрились так накосячить, что это стало заметно, но реальную проблему они так и не исправили.
I>Там история просто писец.
Изумительный мэйнстрим! Знаешь, после таких историй я даже рад, что L2S никто не трогает.
I>А затем что "яка розумная цьому альтернатыва", как говоривал украинский классик. По сути — только BLToolkit.
И L2S.
I>Но если коснуться маркетинга, саппорта и т.д. — то увы, тут все очень грустно.
Зачем тебе маркетинг и саппорт, если инструмент just works? Я понимаю зачем нужен саппорт в EF, они каждую версию фигачат заново и делают ее хуже и хуже, но тут-то... Тебе шашечки или ехать?
I> В смысле надоест тебе его развивать или уедешь ты в отпуск на 3 месяца — и усе. Ни саппорта ни фикса критических багов. опять таки комьюнити, в разы меньше.
В BLT код не такой сложный, чтобы критический баг нельзя было поправить самому или быстро догадаться как обойти. Нет, если интересно всем миром в какашках ковыряться, то ктож вам доктор, но мне гораздо интереснее практические задачи решать.
Знаешь, я конечно не люблю аналогии, особенно из автопрома, но тут прямо напрашивается — в девяностых многие кулибины не хотели покупать иномарки потому что "непонятно как работает и запчастей не найдешь, а жигуленок хоть и ломается, зато всегда есть сосед с гаражем, где любую детальку можно выточить"...
I>Но у этих людей власть.
А что толку? Результат этой власти — на лицо.
I>Возражение "не мейнстрим" забавны? нуну
Именно.
I>Где реальные юзкейсы, приведи хоть один.
Я уже целый ворох привел.
I>Ты сходу привел несколько вещей которые "нельзя сделать в ef". По факту оказалось что можно.
Нет, не оказалось. Просто тебе очень хочется чтобы оказалось, но увы.
Здравствуйте, itslave, Вы писали:
I>ну дык все ж решается с ходу прям там и написано как. И гуглится элементарно. Точно, проблема надумана.
Кстати, а кто ответит: зачем пихать все результаты в один запрос вида
SELECT
[Extent1].ABC, ... -- все свойства Extent1
[Extent2].XYZ, ... -- все свойства Extent2FROM [dbo].[Department] AS [Extent1]
LEFT OUTER JOIN [dbo].[Course] AS [Extent2]
ON [Extent1].[DepartmentID] = [Extent2].[DepartmentID]
?
Чем плохи два последовательных select-а для мастера и detail--ов?
*(особенно если учитывать, что у одного "большого" запроса реальный план выполнения будет дороже в два — в три раза).
Здравствуйте, IB, Вы писали:
IB>Я вроде бы достаточно ясно излагаю — нет? Еще раз: IB>LL — не отключается. Команда "LL-отключись!" по факту вовсе не означает, что можно работать так, как буд-то LL нет, она лишь означает, вместо логики LL будет кидаться исключение, но нормально работать со стандартным синтаксисом все равно нельзя. IB>Поэтому нет, LL — не отключается, его потроха все равно торчат и мешают работать.
Иван, позволь уточнить, как именно ты проводишь эти эксперименты. Полагаю, у тебя есть edmx-модель, по которой сгенерирован код. Убедись, плз, что для генерации кода выбран T4 шаблон ADO.NET POCO Entity Generator, например как здесь. В противном случае генерируются классы сущностей, прибитые гвоздями к ДатаКонтексту, и охотно верю, что там при обращении к незагруженному навигационному свойству будет бросаться исключение.
И вообще, свежее веяние в EF — Code-First Development, вот там ты действительно скармливаешь ему свои POCO-классы, возможно уже ранее написанные и использующиеся в приложении.
Да, всё сказанное предполагает, что используется минимум EF v4 (VS 2010). Первая её версия (из VS 2008) действительно ничего вышеперечисленного не позволяла.
Здравствуйте, IB, Вы писали:
IB>LL — не отключается. Команда "LL-отключись!" по факту вовсе не означает, что можно работать так, как буд-то LL нет, она лишь означает, вместо логики LL будет кидаться исключение, но нормально работать со стандартным синтаксисом все равно нельзя. IB>Поэтому нет, LL — не отключается, его потроха все равно торчат и мешают работать.
Еще раз. Если по команде "LL, Отключись" данные не грузятся при первом к ним обращении, то это значит что LL отключается.
IB>Конечно не дождешься, если игнорировать будешь, я достаточно ясно написал — navigation property это не POCO.
Не хошь — не юзай, тебя никто не заставляет. МОжно и без них жить, в чем то понятней и удобней, в чем то нет.
I>>Я про маппинг нигде ни слова не говорил. Я говорил про кеширование linq-запросов, т.е. sql-запрос не строится каждый раз из linq. IB>Твоюжмать. Что в лоб, что полбу. Еще раз: тормоза на построении запроса и получении результата обратно — это другой порядок малости, по сравнению с тормозами от не эффективного SQL-я.
Ышо рас. Генерируемый скл досаточно хорош для 80% случаев. Если он вдруг вышел кривой, этовсегда можно поправить костылями. Генерить оптимальный запрос который будет оптимальным всегда и везде невозможно, ваш кэп.
I>>А затем что "яка розумная цьому альтернатыва", как говоривал украинский классик. По сути — только BLToolkit. IB>И L2S.
Как только провайдеры под большинство популярных субд допилят, так сразу буду доавблять "... и L2S". А их недопилят никогда, потому как большие дяди решили что L2S не нужен.
I>>Но если коснуться маркетинга, саппорта и т.д. — то увы, тут все очень грустно. IB>Зачем тебе маркетинг и саппорт, если инструмент just works? Я понимаю зачем нужен саппорт в EF, они каждую версию фигачат заново и делают ее хуже и хуже, но тут-то... Тебе шашечки или ехать?
Затем, что я тупо не хочу фиксить баги, мигрировать на новые фреймворки и допиливать BLT своими силами, если тебе вдруг надоест.
IB>Знаешь, я конечно не люблю аналогии, особенно из автопрома, но тут прямо напрашивается — в девяностых многие кулибины не хотели покупать иномарки потому что "непонятно как работает и запчастей не найдешь, а жигуленок хоть и ломается, зато всегда есть сосед с гаражем, где любую детальку можно выточить"...
И в 90х это было правильно мнение, если вдруг обламались, то в гаражах любой завсегдатай может подшаманить за поллитры и машина поедет прям щас. Альтернатива — месяцами ищем специалиста и запчасти, платим ногоденег и затем может быть поедем. Если со специалистом не ошиблись. Аналогия налицо
I>>Но у этих людей власть. IB>А что толку? Результат этой власти — на лицо.
Результат этой власти — в l2s нет и никогда не будет родных провайдеров под постгрес, оракл и прочие субд.
I>>Ты сходу привел несколько вещей которые "нельзя сделать в ef". По факту оказалось что можно. IB>Нет, не оказалось. Просто тебе очень хочется чтобы оказалось, но увы.
Скажем так: на деле EF работает, но не соответствует твоему мировоззрению. Это печально, но в общем то не смертельно. Другому человеку напомнил бы пословицу про караван и собак, но в твоем случае надеюсь, что(в том числе) под влиянием BLT, в EF основные косяки поправят.
Здравствуйте, Sinix, Вы писали:
S>Здравствуйте, itslave, Вы писали:
I>>ну дык все ж решается с ходу прям там и написано как. И гуглится элементарно. Точно, проблема надумана.
S>Кстати, а кто ответит: зачем пихать все результаты в один запрос вида S>
S> SELECT
S> [Extent1].ABC, ... -- все свойства Extent1
S> [Extent2].XYZ, ... -- все свойства Extent2
S> FROM [dbo].[Department] AS [Extent1]
S> LEFT OUTER JOIN [dbo].[Course] AS [Extent2]
S> ON [Extent1].[DepartmentID] = [Extent2].[DepartmentID]
S>
S>?
S>Чем плохи два последовательных select-а для мастера и detail--ов? S>*(особенно если учитывать, что у одного "большого" запроса реальный план выполнения будет дороже в два — в три раза).
Потому что серебряной пули не существуют. Они максимально точно повторили семантику запроса. Никто не запрещает грузить в 2 захода, ручками.
Здравствуйте, itslave, Вы писали:
I>Потому что серебряной пули не существуют. Они максимально точно повторили семантику запроса. Никто не запрещает грузить в 2 захода, ручками.
Текущий вариант отвратительно масштабируется, если нам нужно загружать несколько разных коллекций детей. Лучше уж загружать по умолчанию в несколько запросов, а если кому-то важна точная семантика — вперёд, ручками
Если нам не помогут, то мы тоже никого не пощадим.
Мы уже победили, просто это еще не так заметно...
