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


G>Все что ты озвучивал конкретное касалось старых версий.
И по прежнему актуально для текущей.

G>Про "неадекватность идеи" как не было ответа, так и нет.
Было — почитай внимательнее. Неадекватность идеи заключается в попытке создать FullBlown ORM с попыткой полностью абстрагироваться от БД с не явным LazyLoading-ом и шлюхами. Первое понимание того, что эта абстракция дырявая стало приходить еще лет 10-15 назад по опыту использования EJB, а к моменту факапа WinFS это стало очевидно большинству практикующих разработчиков, но некоторые теоретики до сих пор упорствуют в своем заблуждении... А в данном случае, все было реализовано еще и в гипертрофированном варианте, когда создается некоторая промежуточная метамодель данных через которую и ведется вся работа с БД и кодом. Именно эта идея дожила со времен ObjecSpaces, и именно этот кусок прибит к EF гвоздями и не позволяет сделать из него приличный продукт.

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

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


G>>Все что ты озвучивал конкретное касалось старых версий.
IB>И по прежнему актуально для текущей.
Нет, не актуально.

G>>Про "неадекватность идеи" как не было ответа, так и нет.
IB>Было — почитай внимательнее. Неадекватность идеи заключается в попытке создать FullBlown ORM с попыткой полностью абстрагироваться от БД с не явным LazyLoading-ом и шлюхами.
Что такое FullBlown ORM, чем он отличается от не-FullBlown ?
LL по умолчанию выключен для code-first.

IB>Первое понимание того, что эта абстракция дырявая стало приходить еще лет 10-15 назад по опыту использования EJB, а к моменту факапа WinFS это стало очевидно большинству практикующих разработчиков, но некоторые теоретики до сих пор упорствуют в своем заблуждении... А в данном случае, все было реализовано еще и в гипертрофированном варианте, когда создается некоторая промежуточная метамодель данных через которую и ведется вся работа с БД и кодом.
Метамодель есть в любом ORM, так как одни и те же Linq запросы могут по разному мапиться в разных СУБД. Ты считаешь что это плохо?

IB>Именно эта идея дожила со времен ObjecSpaces, и именно этот кусок прибит к EF гвоздями и не позволяет сделать из него приличный продукт.
Эта фраза ни о чем, ибо программист, использующий Code First никогда эту метамодель не увидит. Вообще modеl-first подход, который ты пытаешься ругать, не используется по факту нигде. Даже из готовой базы ef предлагает сгенерировать code-first модель и не париться с edmx.

Повторю — твое мнение основано на ef версии 1.0, которая была 5 лет назад. Конечно можно использовать ef6 так же как первую версию, но никто тебя не заставляет это делать.

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

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

G>>Результат (вдохни поглубже):
G>>

G>>Average 2,9131428ms per query
G>>

AP>Сначала надо воспроизвести "багу", потом уже демонстрировать ее устранение. Покажи сначала 700ms на LINQtoSQL, потом 2,9ms на EF. Или покажи, что Sam Saffron врет.

Хорошая идея, сделал модель Linq2SQL по базе, сгенерированной ef, оставил тот же тестовый код и получилось 9мс на запрос.
После этого перечитал пост Сэма и выяснил несколько вещей:

Во-первых 700мс это время между предыдущим событием в логе и следующим, даже если принять на веру что все это Linq2SQL, то...
Во-вторых причины исходного тормозняка остались неизвестны, это могло быть:
1) Тупо тормоза в СУБД из-за неэффективного плана
2) Старая версия Linq2SQL до .NET 4.5 работала значительно медленнее (от генерации SQL, то материализации объектов), хотя пост и написан в 2011 году, могли использовать еще .NET 3.5
3) Проблемы, связанные с конкурентным доступом
Да, переход на Dapper исправляет всю пачку проблем, но вполне возможно что значительного ускорения можно было бы добиться другими средствами. Но, к сожалению, у Сэма большой bias в сторону Dapper.
В-третьих — нету результатов "забегов", только декларация что стало сильно быстрее. Есть подозрение, что кроме переписывания на Dapper еще много чего было подкручено.

Кстати на сегодня в EF подавляющее большинство проблем, которые возникали в Linq2SQL были поправлены.

AP>А так не понятно, что за цифры ты привел. Скриншотам MiniProfiler-а с реального продакшена от Sam Saffron более убедительны, чем твои выдуманные примеры.

Специально для тебя опубликовал все исходники. Скопируй их в свое решение и прогони тесты.

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

G>Если связи меняешь, то пишешь скрипт руками.
G>EF генерит скрипт миграции, который можно посмотреть.

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

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

F> Ты сейчас про что? Кеширование запросов было и есть в BLToolkit/linq2db. Есть подобие автоматического, есть и ручное. Насчет ручного — я точно не ошибаюсь — а там дальше — нужно IT призывать. Благо ж форумчанин наш.

Кеширование ET было изначально. А вот ручной Compile появился не сразу и то, только потому, что публика хотела. В реальности в L2DB/BLT он даёт прирост всего в несколько процентов.

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

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

G>>Если связи меняешь, то пишешь скрипт руками.
G>>EF генерит скрипт миграции, который можно посмотреть.

IT>Понятно. Всё как обычно, в простейших случаях, особенно годных для демонстраций, работает, а что-то чуть сложнее, то нужно самому закатывать рукава. Чудес всё-таки не бывает. В таком случае мне лично кажутся более предпочтительными традиционные решения.

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

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

G>Нет, не актуально.
Актуально.

G>LL по умолчанию выключен для code-first.
mode=off, вовсе не означает, что этот механизм не вмешивается в работу. Мне реально лень повторять то, что я писал два года назад — отмотай топик, там подробно расписаны все мои претензии к LL и тому как он якобы "отключается".

G>Метамодель есть в любом ORM, так как одни и те же Linq запросы могут по разному мапиться в разных СУБД.
В твоем утверждении сразу несколько ошибок. Во-первых далеко не все ORM рассчитаны на работу с несколькими СУБД, а во-вторых — наличие метамодели не является необходимым условием для маппинга из линка в SQL, так как POCO классы в купе с метаданными — вполне себе универсальная модель и нет совершенно никаких причин придумывать еще какого-то посредника.

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

G>Эта фраза ни о чем, ибо программист, использующий Code First никогда эту метамодель не увидит.
Совершенно не важно, видит он ее или нет. Важно что эта модель занимает память и время, и ухудшает качество генерируемого SQL. Так что нет, эта фраза очень даже о чем.
code-first — это вообще отдельный бред, ну да и без него проблем хватает, так что даже не буду начинать.

G>Повторю — твое мнение основано на ef версии 1.0, которая была 5 лет назад.
Мое мнение основано на последней версии EF, которую я весьма подробно изучил с целью перехода на нее наших продуктов, после чего выкинул и вымыл руки с мылом.

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


IT>Кеширование ET было изначально. А вот ручной Compile появился не сразу и то, только потому, что публика хотела. В реальности в L2DB/BLT он даёт прирост всего в несколько процентов.
С EF все еще хуже, там выигрыш за счет кеширования — просто другой порядок малости по сравнению с тем на сколько неэффективный SQL он генерит.

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

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

G>>Нет, не актуально.
IB>Актуально.
Ни капли.

G>>LL по умолчанию выключен для code-first.
IB>mode=off, вовсе не означает, что этот механизм не вмешивается в работу.
Не вмешивается вообще, не генерируются прокси, для всех коллекций просто значение null.

IB>Мне реально лень повторять то, что я писал два года назад — отмотай топик, там подробно расписаны все мои претензии к LL и тому как он якобы "отключается".
Это уже давно не актуально. Ты вообще видел code-first в EF6?


G>>Метамодель есть в любом ORM, так как одни и те же Linq запросы могут по разному мапиться в разных СУБД.
IB>В твоем утверждении сразу несколько ошибок. Во-первых далеко не все ORM рассчитаны на работу с несколькими СУБД, а во-вторых — наличие метамодели не является необходимым условием для маппинга из линка в SQL, так как POCO классы в купе с метаданными — вполне себе универсальная модель и нет совершенно никаких причин придумывать еще какого-то посредника.
А метаданные и метамодель чем отличаются?


G>>Ты считаешь что это плохо?
IB>Да. Так как лишняя косвенность, только усугубляет проблемы трансляции из одного языка в другой.
Ты code-first видел? Там нет никакой косвенности.


G>>Эта фраза ни о чем, ибо программист, использующий Code First никогда эту метамодель не увидит.
IB>Совершенно не важно, видит он ее или нет. Важно что эта модель занимает память и время, и ухудшает качество генерируемого SQL. Так что нет, эта фраза очень даже о чем.
А метаданные для мепинга не занимаюсь память и время? И улучшают SQL?
Особенно интересно как это происходит когда классы мапятся 1-в-1 на базу.
Пример приведешь? Или только голословные утверждения будут?

IB>code-first — это вообще отдельный бред, ну да и без него проблем хватает, так что даже не буду начинать.
О, да, одни факты.


G>>Повторю — твое мнение основано на ef версии 1.0, которая была 5 лет назад.
IB>Мое мнение основано на последней версии EF, которую я весьма подробно изучил с целью перехода на нее наших продуктов, после чего выкинул и вымыл руки с мылом.
Знаешь что странно, ты говорил тоже самое два года назад (слово в слово). Про те же самые проблемы. Проблемы исправили (с тем же LL), а слова ты продолжаешь повторять.
Это наводит на мысль, что 2 года назад крайний раз ты и видел ef, причем видимо версии 4.

Всетаки изучи ef6, начни отсюда: http://msdn.microsoft.com/en-US/data/ee712907#codefirst

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

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


IT>>Кеширование ET было изначально. А вот ручной Compile появился не сразу и то, только потому, что публика хотела. В реальности в L2DB/BLT он даёт прирост всего в несколько процентов.
IB>С EF все еще хуже, там выигрыш за счет кеширования — просто другой порядок малости по сравнению с тем на сколько неэффективный SQL он генерит.

Покажи пример где EF последней версии генерит неэффективный запрос.

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

G>От написания скриптов не денешься никуда, миграции лишь синхронизируют запуск скриптов и обновление кода.

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

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

G>Метамодель есть в любом ORM, так как одни и те же Linq запросы могут по разному мапиться в разных СУБД.

А в чём тут проблема, если не секрет?

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

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

G>>От написания скриптов не денешься никуда, миграции лишь синхронизируют запуск скриптов и обновление кода.

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

Ну так заверни тоже самое в миграции и все эти шаги будут еще и синхронно с обновлением кода идти. Кто тебе сказал что надо писать сложные скрипты? Наоборот, в миграциях надо писать очень простые скрипты.

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

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

G>>Метамодель есть в любом ORM, так как одни и те же Linq запросы могут по разному мапиться в разных СУБД.

IT>А в чём тут проблема, если не секрет?

Неправильно написал. Я имел ввиду что в одном случае могут использоваться DML операторы, а в другом будет мапинг сущностей на хранимки.

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

G>Ни капли.
Вера — страшная штука, мне совершенно не интересно тебя убеждать, если веришь что там проблем нет, значит для тебя это так.

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

G>Это уже давно не актуально. Ты вообще видел code-first в EF6?
Да задрал уже. Да, я видел 6.0, я смотрел code-first. Очевидно там где-то завелся генератор ущербных идей, они берут все худшее из других проектов и доводят это до абсурда.

G>А метаданные и метамодель чем отличаются?
Тем, что метамодель это дополнительный набор сущностей, которые служат посредниками между POCO с метаданными и базой. И весь маппинг выполняется через этого посредника. Ни скорости, ни оптимальности запросам этот посредник не добавляет, а делает совсем наоборот.

G>Ты code-first видел? Там нет никакой косвенности.
Да-да, нет никакой ложки.

G>Пример приведешь? Или только голословные утверждения будут?
Не веришь мне — поверь самим разработчикам. " As a result, there are many seldom used features and capabilities in the code base that hamper performance and complicate development, but are not feasible to remove due to the monolithic nature of the implementation."
У них, конечно, тоже только голословные утверждения, но к счастью они обладают возможностью выкинуть это изделие на свалку, что они с сделали.

G>Знаешь что странно, ты говорил тоже самое два года назад (слово в слово). Про те же самые проблемы.
Так с тех пор ничего принципиально не поменялось. А говорить я это начал не два года назад, а практически с момента появления EF, при этом относительно тщательно изучая каждый их новый релиз. Но поскольку проблемы там скорее идеологические, то хвосты ObjectSpaces там торчат до сих пор, как следствие, суть моих претензий не поменялась. А теперь наконец и разработчики признали, что зашли в тупик.

G>Всетаки изучи ef6, начни отсюда: http://msdn.microsoft.com/en-US/data/ee712907#codefirst
Изучать EF нет никакого смысла, его наконец-то похоронили. Даже разработчики признали, что фигня получилась, так что не понимаю чего ты тут с таким жаром защищаешь.

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

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

G>>Ни капли.
IB>Вера — страшная штука, мне совершенно не интересно тебя убеждать, если веришь что там проблем нет, значит для тебя это так.
Это ты уверяешь что проблемы есть, но примеры не приводишь. Воистину — вера страшная штука.

G>>Не вмешивается вообще, не генерируются прокси, для всех коллекций просто значение null.
IB>проблема не в null, а в том, что когда пытаешься построить запрос — летит исключение.
Покажи пример


G>>Это уже давно не актуально. Ты вообще видел code-first в EF6?
IB>Да задрал уже. Да, я видел 6.0, я смотрел code-first. Очевидно там где-то завелся генератор ущербных идей, они берут все худшее из других проектов и доводят это до абсурда.
Судя по тому что ты пишешь — нет.

G>>А метаданные и метамодель чем отличаются?
IB>Тем, что метамодель это дополнительный набор сущностей, которые служат посредниками между POCO с метаданными и базой. И весь маппинг выполняется через этого посредника. Ни скорости, ни оптимальности запросам этот посредник не добавляет, а делает совсем наоборот.
А атрибуты не добавляют? Такие же классы, также через них маппинг делется.



G>>Знаешь что странно, ты говорил тоже самое два года назад (слово в слово). Про те же самые проблемы.
IB>Так с тех пор ничего принципиально не поменялось. А говорить я это начал не два года назад, а практически с момента появления EF, при этом относительно тщательно изучая каждый их новый релиз. Но поскольку проблемы там скорее идеологические, то хвосты ObjectSpaces там торчат до сих пор, как следствие, суть моих претензий не поменялась. А теперь наконец и разработчики признали, что зашли в тупик.
Ты как-то хитро отбросил часть моей фразы про исправление конкретных проблем. Твои идеи по поводу "идеологии" не интересуют вообще, я про конкретику уже хрен знает какой раз спрашиваю, а ответа все нет, ты все про идеологию.

G>>Всетаки изучи ef6, начни отсюда: http://msdn.microsoft.com/en-US/data/ee712907#codefirst
IB>Изучать EF нет никакого смысла, его наконец-то похоронили. Даже разработчики признали, что фигня получилась, так что не понимаю чего ты тут с таким жаром защищаешь.
Не похоронили, а наконец собрались переписать. Текущая версия отлично работает для тех сценариев, для которых она заточена.
С точки зрения API в новой версии мало что изменится, будет вполне нормальный upgrade path.

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

G>Да, не понимаю, покажи компилируемый пример с реальной проверкой. Тем более GoldCutomer может быть совсем в другой сборке и вообще не знать о том какой там исходный запрос.
Вот тут код. Если в строке с номером 29 заменить "c" на "c2", то автоматическая проверка укажет, что надо внести изменения в запросы в строках с номерами 5 и 12.

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

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

G>>Да, не понимаю, покажи компилируемый пример с реальной проверкой. Тем более GoldCutomer может быть совсем в другой сборке и вообще не знать о том какой там исходный запрос.
AP>Вот тут код. Если в строке с номером 29 заменить "c" на "c2", то автоматическая проверка укажет, что надо внести изменения в запросы в строках с номерами 5 и 12.
1) чем это компилировать?
2) где гарантия что GoldCutomer надо вызвать для списка кастомеров?
3) что будет если GoldCutomer будет определен в другой сборке?

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

G>1) чем это компилировать?
Приведенный код компилируется обычным C# компилятором. Для проверки запросов надо дернуть метод CheckAllQueries

QueryChecker.CheckAllQueries(GetType().Assembly.GetTypes(), ConnectionString);

Метод CheckAllQueries анализирует IL код.


G>2) где гарантия что GoldCutomer надо вызвать для списка кастомеров?
Метод GoldCutomer просто подставляет кусок текста. Проверяется лишь, что итоговый запрос валидный. Т.е. если "с" будет иметь нужные колонки, то проверка пройдет.

G>3) что будет если GoldCutomer будет определен в другой сборке?
При компиляции Razor шаблона подставляются все сборки, на которые ссылается сборка с запросом. Можно и явно задавать набор сборок и using-ов, привязывая их к (MethodBase method, string file, int line). method -- метод, в котором находится запрос.

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

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

G>>Да, не понимаю, покажи компилируемый пример с реальной проверкой. Тем более GoldCutomer может быть совсем в другой сборке и вообще не знать о том какой там исходный запрос.
AP>Вот тут код. Если в строке с номером 29 заменить "c" на "c2", то автоматическая проверка укажет, что надо внести изменения в запросы в строках с номерами 5 и 12.

Ну и самый главный косяк. У тебя по сути нет комбинирования запросов. Если добавить в Cutomer поле, то его надо будет прописать во все релевантные запросы. Для linq надо будет поправить функцию, накладывающую проекцию на запрос.