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

IB>Какая прелесть... ж)) Один кейс? да это я просто ногтем ковырнул.
IB>Ничего, что этот кейс — больше половины всех запросов к базе в обычном приложении? Ты предлагаешь каждый left join в ручную выпиливать? Зачем тогда вообще ORM нужен?

А что там за проблемы с left join в EF?

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

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

G>>1) нельзя навесить хинты. Это вообще-то не правда, но люди упорно повторяют эту глупость.

AK>А "хинт" это что?

http://msdn.microsoft.com/en-us/library/ms187713.aspx

G>>2) генерирует плохие запросы. Правда известен ровно один случай плохих запросов — при использовании навигационных свойств и то можно обойти. В среднем генерирует запросы лучше людей.

AK>Навигационные свойства это что? Это "курсоры", или что-то другое?
Нет

Такой linq:

var query = from m in db.Master
            from d in m.Details // Mater.Details: ICollection<Detail>
            select new { m.Title, d.Title}

Превращается примерно в такой SQL

select m.Title, d.Title
from Master m
left join Details d on m.Id = d.MasterId

То есть способ не писать left join руками в Linq.
Так вот в EF появляется дополнительно вычисляемое поле, по которому потом идет сортировка. Это дает заметный оверхед если все страницы в памяти и менее 1% если страницы данных на диске для небольших выборок.


G>>5) нельзя использовать все возможности sql. но никто не мешает сделать функцию и замапить её через ef или напрмую вызвать sql через ef.

AK>Да, про вызов хранимых процедур из EF я знаю, но в идеале я хотел бы избавиться от хранимых процедур полностью.
AK>А какие именно возможности SQL нельзя использовать через EF?
Например в linq нельзя написать MERGE оператор, использовать output выражения, табличные параметры для функций, FullTextSearch, ranking функции pivot\untivot и много чего еще. Большую часть можно обойти изобретением своих функий, но иногда проще тупо SQL написать.

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

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

G>>Для миграции старого проекта возьми linq2db. Он работает быстрее ef,

AK>А насколько быстрее и в каких случаях?
AK>Ну т.е... если linq2db в каких-то случаях заметно быстрее EF, то отсюда неявно следует, что EF в этих же случаях заметно медленнее прямого SQL, так? Вот это мне сейчас в первую очередь и интересно — в каких случаях, почему и как с этим бороться. Выбор linq2db как один из обходных путей — добавлю в копилку, нужно будет пощупать его поближе, может быть и на него переползём.

G>>маппинг даже быстрее dapper.

AK>Маппинг выполняется при чтении данных из базы? Или это что-то другое? В EF он медленный?


Мои тесты показывают такой порядок:
1) Запрос к таблице на 5к элементов, получение всех в ридере — 0,8 мс практически чистое время SQL Server ибо SQL Server стоит на локальной машине.
2) То же самое, но с ручной материализацией объектов — 2 мс. То есть на каждую запись выполняется new и присваивание четырех полей из ридера по индексам.
3) Автоматический маппинг с помощью linq2db — 2,3 мс.
4) Автоматический маппинг с помощью dapper — 2,5 мс.
5) Linq запрос с помощью linq2db — 2,7 мс.
6) Автоматический маппинг с помощью EF — 3 мс.
5) Linq запрос с помощью EF — 3,4 мс.

Тесты прогонялись много раз, первые прогоны не учитывались.

Получается чистый оверхед маппинга linq2db — 0,3 мс (2,3 — 2), а EF — 1 мс (3-2). Но в пересчете на один объект это доли микросекунды, так что по факту разница не большая.
Время обработки простого linq запроса (получение SQL запроса из Linq) у linq2DB и EF одинаковое — 0,4 мс. Скорее всего потому что и один и другой запросы кешируют.

Причем все эти величины составляют статистическую погрешность от времени обработки сложного запроса (100-200мс). Тут нужно сравнивать качество генерируемого SQL для реальных случаев, а это только в реальном приложении и получится сделать.

Поэтому выбирать по скорости почти бессмысленно, проще выбирать по фичам:
1) У EF киллер-фича — миграции базы в code-first, в том числе автоматические, и встроенные фишки concurrency, всякие перехватчики и change tracking.
2) linq2db хорошо работает DML, чуть меньше оферхед, но нет многих ORMных возможностей.
И то и другое может быть как хорошо, так и плохо, в зависимости от сценария.

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

AK>Какие ещё минусы есть у Entity Framework? Что может послужить аргументом для отказа от его использования в проекте?
Не претендуя на глобальность, скажу про один из своих проектов:
Обрабатывается очень много данных, поэтому логика вытаскивания данных вынужденно находится в базе (иначе бы вся база в итоге была вытащена в слой бизнес-логики).
А там запросы такие, что простым select-ом ничего не получится вытащить, либо он выполнялся бы неприемлемо долго.
Поэтому в процедурах используется некоторое количество временных таблиц, вставок в них, индексов и даже местами dynamic sql.
Через EF всё это не реализовать. То есть, можно, конечно, оставить это в процедурах, а процедуры дёргать через EF. Но зачем?

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


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

Зачем, если вы тут в производительности потеряете? Кэширование плана, если это огромный запрос, то экономика
трафика и т.д и т.п.

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

AK>Мой вопрос — о минусах EF.
Тогда он точно не правильно сформулирован — я понял его как "какого фига вы вообще пишите SQL".

AK> Переход на EF я рассматриваю как шанс избавиться от хранимых процедур вообще.
В принципе это вариант, но не надо использовать EF для этого, посмотрите на другие альтернативы.

AK>Это ответ на какой-то другой вопрос.
Это ответ на вопрос, как я его понял.

AK>Мой вопрос — про слабые стороны EF.
Ну так и надо было спрашивать )
Основная слабая сторона EF в том, что он насчитывает историю более десяти лет и все это время разработка этого инструмента базировалась на ошибочных представлениях об ORM. Последние несколько лет, они пытались исправить ситуацию, но хвосты торчат до сих пор и мешаются под ногами на каждом шагу. Все остальные частности — лишь следствие, но по факту получился редкостный уродец.
К счастью, уже даже разработчики это осознали и собираются переписать это чудовище с нуля.

AK>А откуда эта информация?
AK>Я поискал, пока ничего не нашёл про то, что новая версия будет писаться с нуля.
http://blogs.msdn.com/b/adonet/archive/2014/05/19/ef7-new-platforms-new-data-stores.aspx

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


AK>А что там за проблемы с left join в EF?
Там проблемы с самим фреймворком, а с left join — лишь следствие.

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

G>С какой версии?
Со второго релиза точно.

G>У тебя замеры есть?
Замеры того, что тормоза от кривого SQL-я больше чем от маппинга?

G>И? Ковырни еще.
А смысл? Я уже наковырял достаточно даже не напрягаясь.
Не говоря уже о том, что продукт и так похоронили.

G> А то из-за одного кейса, который легко обходится, столько шума...
G>Да еще и impact небольшой, дополнительный sort в конце сделается, который на небольшом кол-ве строк никаких проблем не приносит.
жалкая отмазка =) Это базовый функционал.

G>Типы проверять, руками джоин написать не архи-проблема, хоть явно видишь где будет сложный запрос.
...
IB>>А джойны в ручную выпиливать — не гемор? Я уж лучше без генератора объектов проживу, чем без нормального генератора запросов.
G>Парни в SO нормально так жили, не вижу проблем.
Вопросов больше не имею.
У нас просто разные сценарии — code first и прочая фигня для меня лишь обвеска, это даже не должно быт частью ORM. Для меня важно качество генерации запросов, а так же простота, очевидность и предсказуемость использования инструмента.

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

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

G>>У тебя замеры есть?
IB>Замеры того, что тормоза от кривого SQL-я больше чем от маппинга?
Замеры скорости работы Linq2SQL. Или снова все по пресс-релизам?

G>>И? Ковырни еще.
IB>А смысл? Я уже наковырял достаточно даже не напрягаясь.
IB>Не говоря уже о том, что продукт и так похоронили.
жалкая отмазка =) (с)

G>> А то из-за одного кейса, который легко обходится, столько шума...
G>>Да еще и impact небольшой, дополнительный sort в конце сделается, который на небольшом кол-ве строк никаких проблем не приносит.
IB>жалкая отмазка =) Это базовый функционал.
Он не работает чтоли? Я вот глянул проект нашел целый один такой случай. И то в том месте где на скорость работы насрать.

G>>Типы проверять, руками джоин написать не архи-проблема, хоть явно видишь где будет сложный запрос.
IB>...
IB>>>А джойны в ручную выпиливать — не гемор? Я уж лучше без генератора объектов проживу, чем без нормального генератора запросов.
G>>Парни в SO нормально так жили, не вижу проблем.
IB>Вопросов больше не имею.
Тебе же не надо все джоины пилить, только master->detail. Когда джоинишь detail->maser проблем нет.

IB>У нас просто разные сценарии — code first и прочая фигня для меня лишь обвеска, это даже не должно быт частью ORM. Для меня важно качество генерации запросов, а так же простота, очевидность и предсказуемость использования инструмента.
Да я знаю какой у тебя сценарий — почитать пресс-релизы, а потом писать чушь на форуме.

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

IB>Основная слабая сторона EF в том, что он насчитывает историю более десяти лет и все это время разработка этого инструмента базировалась на ошибочных представлениях об ORM. Последние несколько лет, они пытались исправить ситуацию, но хвосты торчат до сих пор и мешаются под ногами на каждом шагу. Все остальные частности — лишь следствие, но по факту получился редкостный уродец.
IB>К счастью, уже даже разработчики это осознали и собираются переписать это чудовище с нуля.

Иван,

Я и сам не в восторге от EF и никому его в здравом уме не порекомендую, но почему-то у меня не возникает желания впрягаться практически в каждый топик с обсуждением оного. Вы же, наверное, самый ярый его здесь противник, но предъявляемые претензии уровня "хвост болтается между ног", "криво через жопу", "враскоряку", "лишний код", "не нужен" и т.д. несколько не канают на профессиональном форуме. Единственный относительно технический довод "против EF" (из более-менее свежих постов) был касательно его странного поведения при left join'ах

Автор: IB
Дата: 01.07.14

-- и только. Складывается впечатление, что EF лично вам чем-то досадил и вы, толком не разобравшись (да-да, я помню про "смотрел самую свежую версию, все проблемы там же и остались", но см. выше про технические аргументы), начали огульно кунать в какашки его и все Heavyweight ORM'в вместе взятые.

Возможно, вы уже подустали повторять одно и то же в разных тредах, но сам факт участия в них говорит об обратном: "враскоряку"-стайл аргументы в ответах присутствуют, а объективности как-то не наблюдается. Возможно, вам стоит один раз собраться, написать в местный блог статейку с перечислением самых одиозных родовых травм EF'а и его технических недостатков и войти таким образом в пантеон развенчателей мифа ORM'ов?

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


IB>Не говоря уже о том, что продукт и так похоронили.


откуда новости?

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


G>>По поводу запросов — только один кейс для EF, где он плохой запрос генерит, и то он элементрано обходится через ручной джоин.
IB>Какая прелесть... ж)) Один кейс? да это я просто ногтем ковырнул.
IB>Ничего, что этот кейс — больше половины всех запросов к базе в обычном приложении? Ты предлагаешь каждый left join в ручную выпиливать? Зачем тогда вообще ORM нужен?

иммете ввиду обычный лефт джойн в эф криво генерится в скл? или хитрый случай?

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

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


G>>>По поводу запросов — только один кейс для EF, где он плохой запрос генерит, и то он элементрано обходится через ручной джоин.
IB>>Какая прелесть... ж)) Один кейс? да это я просто ногтем ковырнул.
IB>>Ничего, что этот кейс — больше половины всех запросов к базе в обычном приложении? Ты предлагаешь каждый left join в ручную выпиливать? Зачем тогда вообще ORM нужен?

А>иммете ввиду обычный лефт джойн в эф криво генерится в скл? или хитрый случай?

Обычный left join для дочерних коллекций:

class Master {
public int Id {get; set;}
public ICollection<Detail> Details {get; set;}
}

class Detail {
public int Id {get; set;}
public int MasterId {get; set;}
public Master Master {get; set;}
}

var query = from m in db.Set<Master>()
            from d in m.Details //вот тут обращение к дочерней коллекции
            select ...

Получится запрос в котором обязательно в конце в плане будет стоять Sort.

Можно обойти:

var query = from m in db.Set<Master>()
            join d in db.Set<Detail>() on m.Id equals d.MasterId into mds
            from md in mdsDefaultIfEmpty() 
            select ...

Увы такой трюк не работает для many-to-many связей, ибо ключей в явном виде в классах не будет.

Если джоинить Detail к Master, то косяков нет. Более того, он еще сам тип джоина выбирает правильно в зависимости от обязательности ключа.
Проблема только когда ты хочешь получить в контексте родительскую запись со всеми дочерними с change tracking, но это нужно только когда ты собираешься потом что-то менять и записывать, поэтому лишний sort в плане запроса ничего не изменит.

ЗЫ. Я багу засабмитил в EF, вроде признали багом, а не "by design". Если еще чего найдется — советую писать в https://entityframework.codeplex.com/workitem/list/advanced

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

G>Тебе же не надо все джоины пилить, только master->detail. Когда джоинишь detail->maser проблем нет.

Сорри, но это очень смешно звучит. Примерно как: "ну подумаешь что в нашей машине при повороте налево усилитель руля не работает. Когда поворачиваешь направо проблем нет!".
Нормальные селекты для master->detail — это обязательное требование для любой серьезной ORM, даже для легковесной типа linq2db. Если с этим проблемы и джойны нужно расписывать руками, то, Ваня абсолютно прав, дальше обсуждать уже нет никакого смысла, и так все уже ясно.

G>Да я знаю какой у тебя сценарий — почитать пресс-релизы, а потом писать чушь на форуме.

Переходишь на личности, некрасиво.

Здравствуйте, Нахлобуч, Вы писали:

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

А меня вот другой вопрос интересует — почему критика в адрес некоторых технологий всегда вызывает у определенных людей жуткое желание с ней спорить до последнего, при помощи некооректных приемов спора в том числе? Это вот, как раз, EF, юнит-тестирование еще, rich data model. Ах да, Немерле вот

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

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

G>>Тебе же не надо все джоины пилить, только master->detail. Когда джоинишь detail->maser проблем нет.

AVK> Сорри, но это очень смешно звучит. Примерно как: "ну подумаешь что в нашей машине при повороте налево усилитель руля не работает. Когда поворачиваешь направо проблем нет!".

Ты прочитай ответы до конца. Эту проблему легко обойти.

G>>Да я знаю какой у тебя сценарий — почитать пресс-релизы, а потом писать чушь на форуме.
AVK>Переходишь на личности, некрасиво.
Знаешь, уже не только я отметил непрофессиональный подход некоторых личностей. Не уподобляйся им.

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

AVK>>Переходишь на личности, некрасиво.
G>Знаешь, уже не только я отметил непрофессиональный подход некоторых личностей. Не уподобляйся им.

Господа, по вашей переписке создаётся впечатление, будто вы в данный момент не смотрите футбол. Совершенно напрасно, прелюбопытнейшее зрелище.

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

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

AVK>>>Переходишь на личности, некрасиво.
G>>Знаешь, уже не только я отметил непрофессиональный подход некоторых личностей. Не уподобляйся им.

Q>Господа, по вашей переписке создаётся впечатление, будто вы в данный момент не смотрите футбол. Совершенно напрасно, прелюбопытнейшее зрелище.

Я предпочитаю курсы на pluralsight смотреть, гораздо полезнее.

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

G>Я предпочитаю курсы на pluralsight смотреть, гораздо полезнее.

Сенсация! Наконец-то найдено занятие полезнее футбола!

Но эмоции болельщиков (хозяев чемпионата мира), чья команда въ*ывает 0:7? Бесценно.

Ошибся в названии темы предыдущего комментария. Извините, был взволнован.