Работаю сейчас над двумя проектами на C#, где есть базы данных с кучей хранимых процедур, а для доступа к данным используются какие-то обёртки для выполнения этих самых процедур. Один проект — legacy, второй свеженаписанный.
Оно как бы работает, но есть определённые проблемы. Из наиболее значимых проблем — трудности написания юнит-тестов для хранимых процедур (на данный момент, если не ошибаюсь, у нас нет ни одного юнит-теста для SQL-кода) и сложность поддержки и развития всего этого великолепия. Сейчас на legacy-проекте есть полтора разработчика, которые хорошо ориентируются в имеющихся SQL-процедурах, а для остальных (и меня в том числе) любое исправление логики в SQL выливается как минимум в час раскуривания, "а как же оно работает". Размеры хранимых процедур достигают нескольких сотен строк, внутри там бывает десяток JOIN'ов, CROSS APPLY и прочих премудростей, которые при беглом прочтении кода понять трудно. История последних найденных багов показывает, что SQL-код исправлять приходится довольно часто (бизнес-правила часто меняются и добавляются), а делать это сложно и долго.
Хочу предложить коллегам мигрировать на Entity Framework. С тем, чтобы сначала использовать его для вызова имеющихся хранимых процедур и постепенно, по мере доработки кода, переписывать хранимые процедуры на LINQ-запросы. Ну это чтобы не ломать то, что есть и не тратить полгода на переписывание с нуля. Чтобы миграция была плавной и наименее болезненной. Сейчас готовлю документ с моими предложениями и описанием предлагаемой процедуры миграции. В конце хочется полностью избавиться от бизнес-логики в SQL-коде. Это в идеале.
Так вот. Плюсы использования Entity Framework'а я примерно знаю. А какие у него есть минусы? Какие могут быть доводы против использования Entity Framework? Я слышал, что он несколько уступает по производительности прямым SQL-запросам, но разница исчисляется единицами процентов — пару-тройку процентов производительности мы можем принести в жертву плюсам этого фреймворка. Если где-то будет сильно хуже, то там может оставить пару-тройку хранимых процедур и вызывать их через EF. Юниттестирование с ним тоже не столь просто, но хотябы решаемо — мне уже приходилось писать подобие юнит-тестов для EF, где использовалась временная база данных на реальном SQL-сервере. Это работает, но медленно. А поиски по интернету показывают, что для EF можно создавать базы в памяти — например, используя SQLite.
Какие ещё минусы есть у Entity Framework? Что может послужить аргументом для отказа от его использования в проекте?
На днях я начал писать проект. В проекте есть база MSSQL. Entity Framework не использую, потому что у меня есть некий негативный опыт разбирательства с ним, при попытке подключить его к Постгресу.
решил, что если уж знаний SQL у меня достаточно для написания развесистых хранимок для Постгреса, то тяжелый ORM мне не нужен. Использую linq2db, базу пишу руками, хотя — code first для linq2db не помешал бы. Пока все хорошо. Единственное, я не смог заставить работать шаблон linqdb для генерации модели по базе, что-то ему там с путями в шаблоне не нравится. Таким образом, маппинг тоже пишу руками, благо — база еще маленькая.
Преимущество хранимок вижу в том, что обновление логики в хранимке — один запуск скрипта в консоли БД. Обновление атомарное, вступает в действие моментально. Как сделать подобное же обновление в сервере приложений, не обновляя все приложение и не перезапуская его — пока не знаю.
Также, при работе приложений с базой, в двухзвенке в чем-то упрощается их взаимодействие. Сайт на PHP пишет в базу, десктопное приложение на Delphi читает из базы, сервис на Яве работает с этой же базой. Если делать некую прослойку, и засовывать логику в нее, а не в базу, то придется в этой же прослойке решать:
1) Как передавать данные. В прямом смысле — как. Также база может рассылать обновления сама, в постгресе это listen-notify, подобный механизм нужно будет реализовывать в приложении, изобретать протокол или использовать готовый (какой? чтобы его и php понимал, и ява, и дестктопное приложение c#, которым заменят приложение на Delphi)
2) Как делать разделение доступа и логины-пароли. В базе это все есть. Можно даже row-level security сделать.
3) Что делать с обновлением уже изменившихся данных. В базе это просто поле timestamp, соответственно пишем update... where... and ts = :stamp. Следует ли тянуть таймштампы на уровень приложения и отдавать их клиентам, или надо изобретать что-то еще?
В общем, надо писать, а потом еще и писать, и еще писать. То, что в коде СУБД уже давно написано.
Так же я бы на вашем месте присмотрелся бы к https://github.com/igor-tkachev/bltoolkit .
Сам не работал(только собираюсь), но судя по всему очень крутая вещь. Ну и как минимум комьюнити не далеко(в соседней ветке форума ).
Здравствуйте, Artem Korneev, Вы писали:
AK>Какие ещё минусы есть у Entity Framework? Что может послужить аргументом для отказа от его использования в проекте?
Личный хит-парад:
1) нельзя навесить хинты. Это вообще-то не правда, но люди упорно повторяют эту глупость.
2) генерирует плохие запросы. Правда известен ровно один случай плохих запросов — при использовании навигационных свойств и то можно обойти. В среднем генерирует запросы лучше людей.
3) медленный маппинг. По замерам около 0,2 микросекунды на объект, но видимо слишком много для некоторых.
4) медленная генерация запроса. Бывает, но запрос кэшируется и генерация происходит один раз за время работы приложения.
5) нельзя использовать все возможности sql. но никто не мешает сделать функцию и замапить её через ef или напрмую вызвать sql через ef.
Здравствуйте, Artem Korneev, Вы писали:
AK>Хочу предложить коллегам мигрировать на Entity Framework. С тем, чтобы сначала использовать его для вызова имеющихся хранимых процедур и постепенно, по мере доработки кода, переписывать хранимые процедуры на LINQ-запросы. Ну это чтобы не ломать то, что есть и не тратить полгода на переписывание с нуля. Чтобы миграция была плавной и наименее болезненной. Сейчас готовлю документ с моими предложениями и описанием предлагаемой процедуры миграции. В конце хочется полностью избавиться от бизнес-логики в SQL-коде. Это в идеале.
Для миграции старого проекта возьми linq2db. Он работает быстрее ef, маппинг даже быстрее dapper. Он больше ориентирован работу с базой с помощью запросов — легче будет существующие запросы переписать.
Для нового проекта бери ef с миграциями. это позволит очень быстро развивать приложение.
Здравствуйте, Artem Korneev, Вы писали:
AK>Какие могут быть доводы против использования Entity Framework?
У меня довод простой: потому что уже есть BLToolkit! Простой, надёжный, маленький и полностью контролируемый.
ORM само по себе — хорошая идея, но доведённая до абсурда, воплотилась в виде EF. BLToolkit — это та граница, на которой надо было остановиться.
В целом вопрос не правильно сформулирован, так как проводится неявная параллель "не писать развесистые хранимки" == "использовать EF".
На самом же деле, во-первых и от хранимок/вью даже сейчас есть польза, вне зависимости от того используется ли какой-нибудь ORM, а во-вторых — одним EF-ом набор доступных средств не ограничивается.
В кратце — да, держать бизнес-логику в SQL — не самая лучшая идея, но на практике разработчик выбирает тот инструмент, который ему привычнее. Поэтому даже начиная самый новый проект, разработчик, который в состоянии виртуозно выпиливать по SQL-ю, естественно возьмет SQL. (это, по сути, и есть ответ на вопрос)
Что же касается EF — то среди всех ORM фреймворков, доступных на данный момент — это один из наихудших вариантов. Во-первых, потому что изначально был написан ужасно криво, а во-вторых, потому что текущее направление работ наконец-то закрыли и следующая версия будет написана с нуля, при этом даже сохранение API не гарантируется.
К счастью, есть достаточное количество достойных альтернатив, от linq2SQL (если нужно ограничиться стеком MS) до linq2db.
IB>К счастью, есть достаточное количество достойных альтернатив, от linq2SQL (если нужно ограничиться стеком MS) до linq2db.
Всё же давайте перечислим достойный альтернативы
linq2SQL
linq2db
что еще?
NHibernate?
еще что достойное?
А что не из стека MS? Там же LINQ нету. Разве можно без LINQ?
Здравствуйте, IB, Вы писали:
IB>Здравствуйте, Artem Korneev:
IB>К счастью, есть достаточное количество достойных альтернатив, от linq2SQL (если нужно ограничиться стеком MS) до linq2db.
Linq2SQL работает медленнее EF, не поддерживает Async, не поддерживает codefirst, автоматом не синхронизирует модель с базой. Называть это достойно альтернативой — надо иметь очень сильную веру.
Здравствуйте, gandjustas, Вы писали:
G>Linq2SQL работает медленнее EF,
Ну, это просто не правда — работает он ни чуть не медленнее, во многих местах существенно быстрее, просто за счет того, что умеет генерить адекватный SQL, и не содержит тонну лишнего кода.
G> не поддерживает Async, не поддерживает codefirst,
К счастью.
G>автоматом не синхронизирует модель с базой.
А это вообще его преимущество над EF.
G>Называть это достойно альтернативой — надо иметь очень сильную веру.
Надо соизмерять задачи и средства, а не бросаться оголтело на все что придет в воспаленный мозг некоторых архитекторов.
Здравствуйте, Alexander Polyakov, Вы писали:
AP>linq2SQL AP>linq2db AP>что еще?
Вполне достаточно. iBATIS, LLBNGen в свое время так же были не плохи и LINQ вроде поддерживали — не знаю как сейчас. В целом выбрать есть из чего.
AP>NHibernate?
Тот же EF, только в профиль.
AP>А что не из стека MS? Там же LINQ нету.
Как это нет? вот linq2db — не от MS, а linq есть лучше чем у MS даже.
AP>Разве можно без LINQ?
Можно, но не нужно.
Здравствуйте, IB, Вы писали:
IB>Здравствуйте, gandjustas, Вы писали:
G>>Linq2SQL работает медленнее EF, IB>Ну, это просто не правда — работает он ни чуть не медленнее, во многих местах существенно быстрее, просто за счет того, что умеет генерить адекватный SQL, и не содержит тонну лишнего кода.
У Linq2SQL отсутствует кеширование сгенерированного SQL, он каждый раз честно его генерит.
У Linq2SQL медленнее работает мапинг.
По поводу запросов — только один кейс для EF, где он плохой запрос генерит, и то он элементрано обходится через ручной джоин.
Так что неправду ты пишешь.
G>> не поддерживает Async, не поддерживает codefirst, IB>К счастью.
К твоему — может быть и да. Но для разработчиков — лишний гемор.
G>>автоматом не синхронизирует модель с базой. IB>А это вообще его преимущество над EF.
EF тоже не синхронизирует в режиме Database First.
Зато умеет базу генерить из codefirst.
G>>Называть это достойно альтернативой — надо иметь очень сильную веру. IB>Надо соизмерять задачи и средства, а не бросаться оголтело на все что придет в воспаленный мозг некоторых архитекторов.
Надо как минимум быть честным.
Здравствуйте, gandjustas, Вы писали:
G>У Linq2SQL отсутствует кеширование сгенерированного SQL, он каждый раз честно его генерит.
И это тоже не правда — в linq2SQL кеширование присутствует.
G>У Linq2SQL медленнее работает мапинг.
Не медленне чем в EF, да и не это вносит основные тормоза — по сравнению с плохим запросом тормоза маппинга это просто другой порядок малости.
G>По поводу запросов — только один кейс для EF, где он плохой запрос генерит, и то он элементрано обходится через ручной джоин.
Какая прелесть... ж)) Один кейс? да это я просто ногтем ковырнул.
Ничего, что этот кейс — больше половины всех запросов к базе в обычном приложении? Ты предлагаешь каждый left join в ручную выпиливать? Зачем тогда вообще ORM нужен?
G>К твоему — может быть и да. Но для разработчиков — лишний гемор.
А джойны в ручную выпиливать — не гемор? Я уж лучше без генератора объектов проживу, чем без нормального генератора запросов.
G>Надо как минимум быть честным.
Я уже вижу кто здесь честный.
Здравствуйте, IB, Вы писали:
IB>Здравствуйте, gandjustas, Вы писали:
G>>У Linq2SQL отсутствует кеширование сгенерированного SQL, он каждый раз честно его генерит. IB>И это тоже не правда — в linq2SQL кеширование присутствует.
С какой версии? Я крайний раз в 4.0 профилировал приложение c Linq2SQL видел постоянную перекомпиляцию запросов.
Может он кеширует запросы в рамках одного контекста, но это вообще не кеширование, а хрень.
G>>У Linq2SQL медленнее работает мапинг. IB>Не медленне чем в EF, да и не это вносит основные тормоза — по сравнению с плохим запросом тормоза маппинга это просто другой порядок малости.
У тебя замеры есть?
G>>По поводу запросов — только один кейс для EF, где он плохой запрос генерит, и то он элементрано обходится через ручной джоин. IB>Какая прелесть... ж)) Один кейс? да это я просто ногтем ковырнул.
И? Ковырни еще. А то из-за одного кейса, который легко обходится, столько шума...
Да еще и impact небольшой, дополнительный sort в конце сделается, который на небольшом кол-ве строк никаких проблем не приносит.
IB>Ничего, что этот кейс — больше половины всех запросов к базе в обычном приложении? Ты предлагаешь каждый left join в ручную выпиливать? Зачем тогда вообще ORM нужен?
Типы проверять, руками джоин написать не архи-проблема, хоть явно видишь где будет сложный запрос.
G>>К твоему — может быть и да. Но для разработчиков — лишний гемор. IB>А джойны в ручную выпиливать — не гемор? Я уж лучше без генератора объектов проживу, чем без нормального генератора запросов.
Парни в SO нормально так жили, не вижу проблем.
IB>Вполне достаточно. iBATIS, LLBNGen в свое время так же были не плохи и LINQ вроде поддерживали — не знаю как сейчас. В целом выбрать есть из чего.
iBATIS вроде не был испорчен linq-ом.
За ссылку спасибо. Я пошёл читать тот холивар.. Второй день разбираю.
А>Преимущество хранимок вижу в том, что обновление логики в хранимке — один запуск скрипта в консоли БД. Обновление атомарное, вступает в действие моментально. Как сделать подобное же обновление в сервере приложений, не обновляя все приложение и не перезапуская его — пока не знаю.
У меня ситуация немного сложнее. Серверов несколько, причём на одном из проектов эти сервера работают они на разных версиях приложения и, соответственно, с разными версиями SQL-кода. Это вызвано тем, что обновлением серверов занимаются те команды, которые используют наше приложение и не всегда у них есть время и желание обновляться.
А>Также, при работе приложений с базой, в двухзвенке в чем-то упрощается их взаимодействие. Сайт на PHP пишет в базу, десктопное приложение на Delphi читает из базы, сервис на Яве работает с этой же базой. Если делать некую прослойку, и засовывать логику в нее, а не в базу, то придется в этой же прослойке решать:
[..skip..]
Ну этих проблем у меня нет. Обновления данных в реальном времени мне не нужно, доступа из разных языков тоже, разделение уровней доступа реализовано на уровне приложения (ASP.NET). Я хочу лишь заменить слой доступа к данным.
Здравствуйте, gandjustas, Вы писали:
G>1) нельзя навесить хинты. Это вообще-то не правда, но люди упорно повторяют эту глупость.
А "хинт" это что?
G>2) генерирует плохие запросы. Правда известен ровно один случай плохих запросов — при использовании навигационных свойств и то можно обойти. В среднем генерирует запросы лучше людей.
Навигационные свойства это что? Это "курсоры", или что-то другое?
G>5) нельзя использовать все возможности sql. но никто не мешает сделать функцию и замапить её через ef или напрмую вызвать sql через ef.
Да, про вызов хранимых процедур из EF я знаю, но в идеале я хотел бы избавиться от хранимых процедур полностью.
А какие именно возможности SQL нельзя использовать через EF?
Здравствуйте, gandjustas, Вы писали:
G>Для миграции старого проекта возьми linq2db. Он работает быстрее ef,
А насколько быстрее и в каких случаях?
Ну т.е... если linq2db в каких-то случаях заметно быстрее EF, то отсюда неявно следует, что EF в этих же случаях заметно медленнее прямого SQL, так? Вот это мне сейчас в первую очередь и интересно — в каких случаях, почему и как с этим бороться. Выбор linq2db как один из обходных путей — добавлю в копилку, нужно будет пощупать его поближе, может быть и на него переползём.
G>маппинг даже быстрее dapper.
Маппинг выполняется при чтении данных из базы? Или это что-то другое? В EF он медленный?
Здравствуйте, IB, Вы писали:
IB>В целом вопрос не правильно сформулирован,
Мой вопрос — о минусах EF.
IB>так как проводится неявная параллель "не писать развесистые хранимки" == "использовать EF".
Это неявная параллель — для моей ситуации. Хранимые процедуры у нас уже развесистые и как убедить разработчиков писать их короткими и понятными — я не знаю. Говорил на эту тему несколько раз. И с разработчиками и с тимлидом, а воз и ныне там. Переход на EF я рассматриваю как шанс избавиться от хранимых процедур вообще.
IB>на практике разработчик выбирает тот инструмент, который ему привычнее
Те, кто делал этот выбор, давно уже свалили в другие команды. Года два назад, если не больше. А сейчас есть два разработчика, которые вроде раскурили как оно написано и их это, в принципе, устраивает. И ещё два-три разработчика, которых добавили в проект сравнительно недавно и у которых мозги пухнут при попытке что-то там добавить. Про EF разработчики знают, но похоже, что кроме меня активно им никто не пользовался. Потому хочу предложить рассмотреть возможность миграции.
IB>Поэтому даже начиная самый новый проект, разработчик, который в состоянии виртуозно выпиливать по SQL-ю, естественно возьмет SQL. (это, по сути, и есть ответ на вопрос)
Это ответ на какой-то другой вопрос.
Мой вопрос — про слабые стороны EF. Интересуюсь заранее, чтоб не получилось, что мы на него мигрируем, всё станет ещё хуже и коллеги закидают меня гнилыми помидорами.
IB>Что же касается EF — то среди всех ORM фреймворков, доступных на данный момент — это один из наихудших вариантов. Во-первых, потому что изначально был написан ужасно криво, а во-вторых, потому что текущее направление работ наконец-то закрыли и следующая версия будет написана с нуля, при этом даже сохранение API не гарантируется.
А откуда эта информация?
Я поискал, пока ничего не нашёл про то, что новая версия будет писаться с нуля. Зато нашёл интересный обзор проблем производительности -- http://msdn.microsoft.com/en-US/data/hh949853
Текста много. Пока сам разбираюсь, насколько всё хорошо или плохо и будет ли это критично для нашего случая.
IB>К счастью, есть достаточное количество достойных альтернатив, от linq2SQL (если нужно ограничиться стеком MS) до linq2db.
Да.. на альтернативы тоже посмотрим, но это если EF чем-то отпугнёт. Пока хочется разобраться с ним -- будет ли что-то мешать нормально использовать его на наших задачах.
Здравствуйте, IB, Вы писали:
IB>Какая прелесть... ж)) Один кейс? да это я просто ногтем ковырнул. IB>Ничего, что этот кейс — больше половины всех запросов к базе в обычном приложении? Ты предлагаешь каждый left join в ручную выпиливать? Зачем тогда вообще ORM нужен?
Здравствуйте, 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. Но зачем?
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
Здравствуйте, 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'ах
-- и только. Складывается впечатление, что EF лично вам чем-то досадил и вы, толком не разобравшись (да-да, я помню про "смотрел самую свежую версию, все проблемы там же и остались", но см. выше про технические аргументы), начали огульно кунать в какашки его и все Heavyweight ORM'в вместе взятые.
Возможно, вы уже подустали повторять одно и то же в разных тредах, но сам факт участия в них говорит об обратном: "враскоряку"-стайл аргументы в ответах присутствуют, а объективности как-то не наблюдается. Возможно, вам стоит один раз собраться, написать в местный блог статейку с перечислением самых одиозных родовых травм EF'а и его технических недостатков и войти таким образом в пантеон развенчателей мифа ORM'ов?
HgLab: Mercurial Server and Repository Management for Windows
Re[8]: Почему вы НЕ используете Entity Framework?
От:
Аноним
Дата:
08.07.14 07:33
Оценка:
Здравствуйте, IB, Вы писали:
IB>Не говоря уже о том, что продукт и так похоронили.
откуда новости?
Re[6]: Почему вы НЕ используете Entity Framework?
От:
Аноним
Дата:
08.07.14 07:49
Оценка:
Здравствуйте, 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 в плане запроса ничего не изменит.
Здравствуйте, gandjustas, Вы писали:
G>Тебе же не надо все джоины пилить, только master->detail. Когда джоинишь detail->maser проблем нет.
Сорри, но это очень смешно звучит. Примерно как: "ну подумаешь что в нашей машине при повороте налево усилитель руля не работает. Когда поворачиваешь направо проблем нет!".
Нормальные селекты для master->detail — это обязательное требование для любой серьезной ORM, даже для легковесной типа linq2db. Если с этим проблемы и джойны нужно расписывать руками, то, Ваня абсолютно прав, дальше обсуждать уже нет никакого смысла, и так все уже ясно.
G>Да я знаю какой у тебя сценарий — почитать пресс-релизы, а потом писать чушь на форуме.
Переходишь на личности, некрасиво.
... << RSDN@Home 1.2.0 alpha 5 rev. 100 on Windows 8 6.2.9200.0>>
Здравствуйте, Нахлобуч, Вы писали:
Н>Вы же, наверное, самый ярый его здесь противник, но предъявляемые претензии уровня "хвост болтается между ног", "криво через жопу", "враскоряку", "лишний код", "не нужен" и т.д. несколько не канают на профессиональном форуме.
А меня вот другой вопрос интересует — почему критика в адрес некоторых технологий всегда вызывает у определенных людей жуткое желание с ней спорить до последнего, при помощи некооректных приемов спора в том числе? Это вот, как раз, EF, юнит-тестирование еще, rich data model. Ах да, Немерле вот
... << RSDN@Home 1.2.0 alpha 5 rev. 100 on Windows 8 6.2.9200.0>>
Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, gandjustas, Вы писали:
G>>Тебе же не надо все джоины пилить, только master->detail. Когда джоинишь detail->maser проблем нет.
AVK> Сорри, но это очень смешно звучит. Примерно как: "ну подумаешь что в нашей машине при повороте налево усилитель руля не работает. Когда поворачиваешь направо проблем нет!".
Ты прочитай ответы до конца. Эту проблему легко обойти.
G>>Да я знаю какой у тебя сценарий — почитать пресс-релизы, а потом писать чушь на форуме. AVK>Переходишь на личности, некрасиво.
Знаешь, уже не только я отметил непрофессиональный подход некоторых личностей. Не уподобляйся им.
Здравствуйте, gandjustas, Вы писали:
AVK>>Переходишь на личности, некрасиво. G>Знаешь, уже не только я отметил непрофессиональный подход некоторых личностей. Не уподобляйся им.
Господа, по вашей переписке создаётся впечатление, будто вы в данный момент не смотрите футбол. Совершенно напрасно, прелюбопытнейшее зрелище.
Здравствуйте, Qbit86, Вы писали:
Q>Здравствуйте, gandjustas, Вы писали:
AVK>>>Переходишь на личности, некрасиво. G>>Знаешь, уже не только я отметил непрофессиональный подход некоторых личностей. Не уподобляйся им.
Q>Господа, по вашей переписке создаётся впечатление, будто вы в данный момент не смотрите футбол. Совершенно напрасно, прелюбопытнейшее зрелище.
Я предпочитаю курсы на pluralsight смотреть, гораздо полезнее.
Здравствуйте, gandjustas, Вы писали:
G>Ты прочитай ответы до конца. Эту проблему легко обойти.
Само наличие этой проблемы — скверный сигнал. Это ж не какой то хитровычурный юзкейс, это один из базовых сценариев.
AVK>>Переходишь на личности, некрасиво. G>Знаешь, уже не только я отметил непрофессиональный подход некоторых личностей. Не уподобляйся им.
И опять перешел на личности.
... << RSDN@Home 1.2.0 alpha 5 rev. 100 on Windows 8 6.2.9200.0>>
Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, gandjustas, Вы писали:
G>>Ты прочитай ответы до конца. Эту проблему легко обойти.
AVK>Само наличие этой проблемы — скверный сигнал.
"Скверный сигнал" имеет хоть какое-то отношение к реальным проблемам?
Еще раз повторяю:
1) в linq этот "скверный сигнал" исправляется заменой аж двух строк.
2) Там где исправить нельзя этот "скверный сигнал" имеет влияние на на быстродействие меньше статистической погрешности.
AVK>Это ж не какой то хитровычурный юзкейс, это один из базовых сценариев.
Использование identity map тоже "не хитровычурный юзкейс, это один из базовых сценариев", вот только он в linq2db не поддерживается. Скверный сигнал однако...
AVK>>>Переходишь на личности, некрасиво. G>>Знаешь, уже не только я отметил непрофессиональный подход некоторых личностей. Не уподобляйся им. AVK>И опять перешел на личности.
Потому что проблема не в конкретных ORM, а в людях, выносящих суждения, используя настолько непрофессиональную аргументацию.
Еще раз повторяю: не уподобляйся им.
Re[13]: Почему вы НЕ используете Entity Framework?
Здравствуйте, gandjustas, Вы писали:
AVK>>Это ж не какой то хитровычурный юзкейс, это один из базовых сценариев. G>Использование identity map тоже "не хитровычурный юзкейс, это один из базовых сценариев"
Нет, это не базовый сценарий а заботливо подложенные грабли.
G>, вот только он в linq2db не поддерживается
Совершенно намеренно, замечу. Т.е. это вполне осознанное решение, принятое на основании значительного опыта нескольких людей.
AVK>>И опять перешел на личности. G>Потому что проблема не в конкретных ORM, а в людях
Проблемы, они, конечно, всегда в людях, но здесь технический форум.
G>Еще раз повторяю: не уподобляйся им.
Пока что им уподобляешься ты, с завидным упорством переходя на личности вместо конструктивного разговора.
... << RSDN@Home 1.2.0 alpha 5 rev. 100 on Windows 8 6.2.9200.0>>
Здравствуйте, gandjustas, Вы писали:
AVK>>Это ж не какой то хитровычурный юзкейс, это один из базовых сценариев. G>Использование identity map тоже "не хитровычурный юзкейс, это один из базовых сценариев", вот только он в linq2db не поддерживается. Скверный сигнал однако...
Едва ли он кому-то нужен. А впиндюреный туда намертво — точно не нужен.
Здравствуйте, AndrewVK, Вы писали:
AVK>А меня вот другой вопрос интересует — почему критика в адрес некоторых технологий всегда вызывает у определенных людей жуткое желание с ней спорить до последнего, при помощи некооректных приемов спора в том числе? Это вот, как раз, EF, юнит-тестирование еще, rich data model. Ах да, Немерле вот
Я не до конца понял, в чей огород тут камень, но рискну предположить, что это был выпад в сторону оппонентов IB.
Еще раз повторю свой посыл. Читая сообщения IB (и вообще противников EF'а и тяжеловесных ORM'ов) складывается впечатление, что этот EF -- диавольская технология и вообще худшее, что могло случиться в мире .NET. Возможно. Но аргументация выпадов страдает. Походя бросить "Identity Map/Lazy Loading не нужен потому что гладиолус" или "В EF плохо всё" -- это, бесспорно, очень задорно, но после просьбы как-то более предметно (и с использованием объективных технических аргументов) раскрыть суть претензии запал обычно затухает, нападает лень, члены становятся немощны и в качестве доказательств используются посылы вида "я уже в этом топике рассказывал, поищи, лень одно и то же по цать раз повторять" и "перечитай мое сообщение внимательнее", либо апелляция к собственному опыту "да я смотрел, там ничего не изменилась", либо же цитирование каких-то ветхозаветных (или не относящихся к делу) статей, или, чего хлеще, цитирование соратников по благодатному срачу. И дискуссия в итоге вырождается в "Спор без фактов. Спор на темпераменте. Спор, переходящий от голословного утверждения на личность партнера."
Возможно, вы знаете что-то такое, что могло бы открыть глаза на порочность использования ORM'ов всему RSDN'у. Если это так, то почему бы раз и навсегда не положить конец лютым спорам и не собрать в одном месте все доводы против EF'а и ORM'ов, подкрепив это все для верности верфицируемыми доказательствами (вот про этот разнесчастный left join, пол неотключаемый LL, что там еще)? Там же можно похвастаться боевыми шрамами: "вот я использовал ORM в таком-то проекте и вот как вероломно этот Identity Map укусил меня за жопу" или "использование Lazy Loading привело к тому, что наш сайт стал жрать память и локи на таблицах висели как яблоки на яблоне в урожайную пору".
Нынешний уровень аргументации -- не канает, увы.
HgLab: Mercurial Server and Repository Management for Windows
Здравствуйте, gandjustas, Вы писали:
G>Замеры скорости работы Linq2SQL. Или снова все по пресс-релизам?
В топике про пресс-релизы ты слился, так что не вижу причины повторять это упражнение здесь.
Здравствуйте, Нахлобуч, Вы писали:
Н>Я и сам не в восторге от EF и никому его в здравом уме не порекомендую, но почему-то у меня не возникает желания впрягаться практически в каждый топик с обсуждением оного.
Да я и не впрягаюсь. )
Н>Вы же, наверное, самый ярый его здесь противник,
Вовсе нет. Но, наверное, один из самых последовательных.
Н> но предъявляемые претензии уровня "хвост болтается между ног", "криво через жопу", "враскоряку", "лишний код", "не нужен" и т.д. несколько не канают на профессиональном форуме.
Ну вот так передергивать совсем не красиво — это вовсе не моя терминология. =)
Н> Единственный относительно технический довод "против EF" (из более-менее свежих постов) был касательно его странного поведения при left join'ах
-- и только.
И только?! А сколько таких "и только" нужно?
Для меня ситуация выглядит несколько иначе. Для аудитории, которая считает, что ORM которая криво генерит запросы с left join-ами это "и только" — уровень моей аргументации слишком профессионален, но, к сожалению, опускаться ниже я уже не могу.
Н> Складывается впечатление, что EF лично вам чем-то досадил и вы, толком не разобравшись (да-да, я помню про "смотрел самую свежую версию, все проблемы там же и остались", но см. выше про технические аргументы), начали огульно кунать в какашки его и все Heavyweight ORM'в вместе взятые.
У меня складывается обратное впечатление. Я уже достаточно подробно объяснил, в том числе и в свежих топиках, почему у EF проблемы и откуда они берутся, привел несколько примеров этих проблем и показал почему они остаются в продукте от версии к версии... Собственно ответ "by design" от разработчиков — лишнее подтверждение моей правоты. Что еще надо?
Любое дополнительное количество технических аргументов будет упираться в "и только", но мне это уже давно не интересно...
Н>Возможно, вы уже подустали повторять одно и то же в разных тредах,
Да.
Н>но сам факт участия в них говорит об обратном:
сам факт участия в них ни говорит ни о чем. Мне просто нравится наблюдать как оппоненты сначала пыжутся, напирают, а потом молча сливаются, когда показываешь как все на самом деле происходит
Н> "враскоряку"-стайл аргументы в ответах присутствуют, а объективности как-то не наблюдается.
Ойнупростите, признаю, не объективен. Все-таки у меня какая-то неявная симпатия к EF присутствует и потому был излишне мягок, больше не повторится ))
Н> Возможно, вам стоит один раз собраться, написать в местный блог статейку с перечислением самых одиозных родовых травм EF'а и его технических недостатков и войти таким образом в пантеон развенчателей мифа ORM'ов?
Вот тогда бы я впрягся. =) Но я это упражнение уже несколько раз проделывал — больше не интересно.
Здравствуйте, Нахлобуч, Вы писали:
Н>Нынешний уровень аргументации -- не канает, увы.
Ох какое падение нравов ((
Ну, значит не судьба, от нынешнего уровня аудитории я тоже не в восторге... ;(
Мы уже победили, просто это еще не так заметно...
Re[10]: Почему вы НЕ используете Entity Framework?
От:
Аноним
Дата:
09.07.14 05:56
Оценка:
Здравствуйте, AndrewVK, Вы писали:
AVK>Нормальные селекты для master->detail — это обязательное требование для любой серьезной ORM, даже для легковесной типа linq2db.
а linq2db такое умеет?
Re[14]: Почему вы НЕ используете Entity Framework?
Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, gandjustas, Вы писали:
AVK>>>Это ж не какой то хитровычурный юзкейс, это один из базовых сценариев. G>>Использование identity map тоже "не хитровычурный юзкейс, это один из базовых сценариев" AVK>Нет, это не базовый сценарий а заботливо подложенные грабли.
Нет, это базовый сценарий. Им пользуется на 3 порядка больше людей, чем всем linq2db и dapper вместе взятыми.
G>>, вот только он в linq2db не поддерживается AVK>Совершенно намеренно, замечу. Т.е. это вполне осознанное решение, принятое на основании значительного опыта нескольких людей.
Нескольких это пяти? или шести?
AVK>>>И опять перешел на личности. G>>Потому что проблема не в конкретных ORM, а в людях AVK>Проблемы, они, конечно, всегда в людях, но здесь технический форум.
Именно, поэтому аргументы вроде "скверный сигнал", "грабли" не канают.
Приводи конкретные примеры.
Re[14]: Почему вы НЕ используете Entity Framework?
Здравствуйте, fddima, Вы писали:
F>Здравствуйте, gandjustas, Вы писали:
AVK>>>Это ж не какой то хитровычурный юзкейс, это один из базовых сценариев. G>>Использование identity map тоже "не хитровычурный юзкейс, это один из базовых сценариев", вот только он в linq2db не поддерживается. Скверный сигнал однако... F> Едва ли он кому-то нужен. А впиндюреный туда намертво — точно не нужен.
В теории конечно так, а на практике куча инструментов в .net заточено именно на работу с объектами. Напрмиер model binding в asp.net.
Я попробовал в одном небольшом проекте прикрутить linq2db вместо EF, код распух примерно в 2 раза, функциональности не добавилось.
Про неработоспособность вещей типа dynamic data и odata сервисов даже не буду писать.
Re[10]: Почему вы НЕ используете Entity Framework?
Здравствуйте, IB, Вы писали:
IB>Здравствуйте, gandjustas, Вы писали:
G>>Замеры скорости работы Linq2SQL. Или снова все по пресс-релизам? IB>В топике про пресс-релизы ты слился, так что не вижу причины повторять это упражнение здесь.
Продолжай верить, это путь к успеху.
Re[15]: Почему вы НЕ используете Entity Framework?
AK>Какие ещё минусы есть у Entity Framework? Что может послужить аргументом для отказа от его использования в проекте?
Проект в котором важна скорость обработки данных в СУБД. Избавится от использования хранимых процедур в таких проектах невозможно, иначе придется большие объемы данных тащить в приложение и потом обратно с базой их "джойнить", это всегда эффективнее делать на уровне СУБД. А устраивать зоопарк — часть логики в хранимых на уровне СУБД, часть запросов в приложении — это не очень удобно. Делать из сервера приложений — сервер СУБД который бы ворочал данные тоже не верно.
Re[16]: Почему вы НЕ используете Entity Framework?
Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, gandjustas, Вы писали:
G>>Про неработоспособность вещей типа dynamic data и odata сервисов даже не буду писать.
AVK>Аналог odata там есть, причем кое какие вещи в odata появились только в 4 версии.
Об этом, видимо, знает лишь "несколько людей" (с)
Re[17]: Почему вы НЕ используете Entity Framework?
Здравствуйте, gandjustas, Вы писали:
G>Нет, это базовый сценарий. Им пользуется на 3 порядка больше людей, чем всем linq2db и dapper вместе взятыми.
Похоже у тебя не правильное понятие "базового сценария". Впрочем, мы это выяснили еще в прошлый раз.
G>Нескольких это пяти? или шести?
Да хоть одного, какая разница сколько их?
G>Приводи конкретные примеры.
Да привели тебе уже пример, просто в твоей реальности он не релевантен. Ну нет, так нет. Для тех целей, для которых мы используем ORM — этого примера вполне достаточно, для того чтобы EF дальше даже не рассматривать. Однако в твоих сценариях это норма — ну значит такие сценарии...
Мы уже победили, просто это еще не так заметно...
Re[11]: Почему вы НЕ используете Entity Framework?
Здравствуйте, IB, Вы писали:
IB>Здравствуйте, gandjustas, Вы писали:
G>>Нет, это базовый сценарий. Им пользуется на 3 порядка больше людей, чем всем linq2db и dapper вместе взятыми. IB>Похоже у тебя не правильное понятие "базового сценария". Впрочем, мы это выяснили еще в прошлый раз.
Вот базовые сценарии, который дает нам ASP.NET:
1) Сделать один сложный запрос с проекциями, фильтрами итп, чтобы сформировать объект модели для отображения. Тут можно ручками написать join в linq, это аж одна строка.
2) Замапить данные формы на объект, который сохранить в базе. Тут нужен identity map, но совершенно нет необходимости тянуть связанные объекты.
Единственное место, где мне пригодилось выполнять .Include — в WebAPI контроллере, который отдавал "заказы с позициями", но это априори тяжелым запросом было.
В большинстве случаев доставался или один "заказ с позициями", поэтому лишняя сортировка в плане ни на что не влияла, или "список заказов", совершенно без затягивания лишних элементов.
G>>Нескольких это пяти? или шести? IB>Да хоть одного, какая разница сколько их?
Ты конечно не поверишь, но у подавляющего большинства базовые сценарии, как я описал выше. А твой базовый сценарий встречается у двух с половиной человек.
G>>Приводи конкретные примеры. IB>Да привели тебе уже пример, просто в твоей реальности он не релевантен. Ну нет, так нет. Для тех целей, для которых мы используем ORM — этого примера вполне достаточно, для того чтобы EF дальше даже не рассматривать. Однако в твоих сценариях это норма — ну значит такие сценарии...
Чукча не читатель? Ты прочитай, поймешь что эта проблема обходится одной строчкой. Отсутствие identity map стоит гораздо дороже во многих случаях
Re[12]: Почему вы НЕ используете Entity Framework?
Здравствуйте, IB, Вы писали:
IB>Здравствуйте, gandjustas, Вы писали:
G>>Продолжай верить, это путь к успеху. IB>Хочешь померяться успехами?
Прости, но успехи в чтении пресс-релизов меня не интересуют.
Re[18]: Почему вы НЕ используете Entity Framework?
Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, gandjustas, Вы писали:
G>>Об этом, видимо, знает лишь "несколько людей" (с)
AVK>Кому интересно, тот знает. Этот функционал еще с BLT, со времен когда одата называлась WCF Data Services.
Приведи пример чтоли... Гугл не нашел.
Re[19]: Почему вы НЕ используете Entity Framework?
Здравствуйте, Аноним, Вы писали:
AK>>Какие ещё минусы есть у Entity Framework? Что может послужить аргументом для отказа от его использования в проекте? А>Проект в котором важна скорость обработки данных в СУБД. Избавится от использования хранимых процедур в таких проектах невозможно, иначе придется большие объемы данных тащить в приложение и потом обратно с базой их "джойнить", это всегда эффективнее делать на уровне СУБД.
Насколько я помню, EntityFramework не гоняет данные туда-сюда без нужды. Оно генерирует SQL-запрос и все данные обрабатываются на стороне сервера, т.е. из C# кода вы можете делать с данными почти тоже самое, что и через прямой SQL.
Пересылать данные на сторону сервера приложений оно начинает только тогда, когда Вы эти данные вытаскиваете из IQueryable и начинаете обрабатывать построчно C# кодом. Но это уже вполне логично, это уже выходит за рамки SQL-кода вообще и хранимых процедур в частности.
С уважением, Artem Korneev.
Re[12]: Почему вы НЕ используете Entity Framework?
AK>... мне уже приходилось писать подобие юнит-тестов для EF, где использовалась временная база данных на реальном SQL-сервере. Это работает, но медленно.
Насколько медленно, в миллисекундах сколько и на что тратится?
Н>... и не собрать в одном месте все доводы против EF'а и ORM'ов, подкрепив это все для верности верфицируемыми доказательствами (вот про этот разнесчастный left join, пол неотключаемый LL, что там еще)? ...
Далеко не все вопросы программирования имеют решения в таком ключе, в котором ты ожидаешь. Вот, например, есть две технологии WebForms и ASP.NET MVC. Если начать рассматривать частные случаи, то обе технологии с ними справятся с приемлемым качеством. Но за деревьями не увидишь леса. Сейчас ни один вменяемый разработчик не начнет проект на WebForms.
Здравствуйте, Alexander Polyakov, Вы писали:
Н>>... и не собрать в одном месте все доводы против EF'а и ORM'ов, подкрепив это все для верности верфицируемыми доказательствами (вот про этот разнесчастный left join, пол неотключаемый LL, что там еще)? ... AP>Далеко не все вопросы программирования имеют решения в таком ключе, в котором ты ожидаешь. Вот, например, есть две технологии WebForms и ASP.NET MVC. Если начать рассматривать частные случаи, то обе технологии с ними справятся с приемлемым качеством. Но за деревьями не увидишь леса. Сейчас ни один вменяемый разработчик не начнет проект на WebForms.
Ты удивишься, но некоторые вещи на WebForms делаются гораздо быстрее, чем на MVC.
Например такая задача:
1) Есть страница, на ней два списка. В первом есть элементы, второй пуст.
2) Есть кнопки, которые переносят элементы из первого во второй и наоборот.
3) Есть кнопка, по нажатию на которую пользователь попадает на вторую страницу, на которой выводятся элементы во втором списке.
На формах делается за 15 минут максимум.
Это не абстракная задача, это может пригодиться для создания WebUI для проведения тестов.
Конечно для публичных сайтов WebForms не подходит катострофически, а для корпоративного формошлепства в вебе — вполне. Но веб-формы очень сложны, крайне мало людей умеют их готовить правильно.
Здравствуйте, gandjustas, Вы писали:
G>Ты удивишься, но некоторые вещи на WebForms делаются гораздо быстрее, чем на MVC.
Только лишь за счет того, что для данной задачи контролы лежат в Toolbar студии. И скорее всего (для интранета) нет особых требований к UI/UX.
Если на примете есть js-конторл такого же типа, то и на MVC это задачка такая же по времени.
Re[10]: Почему вы НЕ используете Entity Framework?
Здравствуйте, Doc, Вы писали:
Doc>Здравствуйте, gandjustas, Вы писали:
G>>Ты удивишься, но некоторые вещи на WebForms делаются гораздо быстрее, чем на MVC.
Doc>Только лишь за счет того, что для данной задачи контролы лежат в Toolbar студии. И скорее всего (для интранета) нет особых требований к UI/UX.
Так есть, сила WebForms в контролах с готовым поведением (как клиентским, так и серверным) и имитацией состояния. Хотя во многих случаях это не сила, а слабость.
Doc>Если на примете есть js-конторл такого же типа, то и на MVC это задачка такая же по времени.
Обычный select и button.
Если логика требуется на сервере (расчет результатов теста например), то js контролы не сильно помогут, много кода будет написано чтобы передать-получить данные и увязать их с контролами.
AK>трудности написания юнит-тестов для хранимых процедур
можно подумать есть принципиальная разница между тестированием ХП и кода на шарпе
AK>Сейчас на legacy-проекте есть полтора разработчика, которые хорошо ориентируются в имеющихся SQL-процедурах
Прекрасная новость, как мне кажется
AK> а для остальных (и меня в том числе) любое исправление логики в SQL выливается как минимум в час раскуривания, "а как же оно работает". Размеры хранимых процедур достигают нескольких сотен строк, внутри там бывает десяток JOIN'ов, CROSS APPLY и прочих премудростей, которые при беглом прочтении кода понять трудно.
Не хотите читать чужой код, не хватает квалификации для чтения SQLя — обычное явление
AK>Какие ещё минусы есть у Entity Framework? Что может послужить аргументом для отказа от его использования в проекте?
Минусы в использовании практически любой подобной хрени всегда одни и те же
— слой хранимок/вьюх это слой абстракции отделяющий физическую структуру данных от интерфейса. При наличии dev-DBA он необходим
— слой хранимок/вьюх в разы упрощает обеспечение data integrity
— реализация BL вне хранимок создает лишний трафик, из-за передачи данных из сервера БД
— реализация BL вне хранимок часто категорически неприемлема, если сервер БД _может_ находиться далеко (например издыхание сервера БД в основном ДЦ, и автоматический фэйловер к резервному, до которого пинг 70мс, азуры, амазоны, просто фиговый коннект в корпоративном интранете)
Отсутствие поддержки CTE, temporary tables и прочих идиом SQLя — не принципиальны, пока есть возможность обратиться напрямую запросом
Re[11]: Почему вы НЕ используете Entity Framework?
Здравствуйте, gandjustas, Вы писали:
G>Если логика требуется на сервере (расчет результатов теста например), то js контролы не сильно помогут, много кода будет написано чтобы передать-получить данные и увязать их с контролами.
Да не так уж и много. Json уже вполне хорошо отдается/парсится. Несколько большее чем для готовых контролов, это да. А вот объем самой BL будет тот же, ей то пофиг что там в UI.
Ну и опять же — только стоит попробовать шагнуть в сторону, сразу по скорости будет лучше MVC.
Re[17]: Почему вы НЕ используете Entity Framework?
Здравствуйте, gandjustas, Вы писали:
G>В большинстве случаев доставался или один "заказ с позициями", поэтому лишняя сортировка в плане ни на что не влияла, или "список заказов", совершенно без затягивания лишних элементов.
Ты все еще не понимаешь. Этот пример наглядно показывает, что EF в принципе плохо генерит запросы меняя их в сторону удобства маппинга в ущерб оптимальности. Тебеж не зря ответили, что это не баг, а фича.
G>Ты конечно не поверишь, но у подавляющего большинства базовые сценарии, как я описал выше. А твой базовый сценарий встречается у двух с половиной человек.
Ты продолжаешь не понимать что такое базовый сценарий. Базовый сценарий для ORM — это не только конкретный left join (хотя и это тоже), а умение генерить качественный SQL в целом. EF за это упражнение — твердая двойка.
G>Чукча не читатель?
Я уже вижу кто здесь чукча — тебе уже и разжевали все, и примеры привели, и сами разработчики написали, что "фигня у нас получилась, заново делать будем", а ты все твердишь, что инструмент идеален... Расслабься уже, все у тебя есть.
Мы уже победили, просто это еще не так заметно...
Re[13]: Почему вы НЕ используете Entity Framework?
Здравствуйте, gandjustas, Вы писали:
G>Прости, но успехи в чтении пресс-релизов меня не интересуют.
А напрасно, иногда намного полезнее чем в форуме сраться Прочитал бы парочку, вдумчиво — глядишь и успокоился бы =)
Мы уже победили, просто это еще не так заметно...
Re[18]: Почему вы НЕ используете Entity Framework?
Здравствуйте, IB, Вы писали:
IB>Здравствуйте, gandjustas, Вы писали:
G>>В большинстве случаев доставался или один "заказ с позициями", поэтому лишняя сортировка в плане ни на что не влияла, или "список заказов", совершенно без затягивания лишних элементов. IB>Ты все еще не понимаешь. Этот пример наглядно показывает, что EF в принципе плохо генерит запросы меняя их в сторону удобства маппинга в ущерб оптимальности. Тебеж не зря ответили, что это не баг, а фича.
Это женская логика. Единичный пример не показывает ничего "в принципе". Также как единичный баг не говорит о качестве приложения "в принципе".
G>>Ты конечно не поверишь, но у подавляющего большинства базовые сценарии, как я описал выше. А твой базовый сценарий встречается у двух с половиной человек. IB>Ты продолжаешь не понимать что такое базовый сценарий. Базовый сценарий для ORM — это не только конкретный left join (хотя и это тоже), а умение генерить качественный SQL в целом. EF за это упражнение — твердая двойка.
Докажи это, пока у тебя один конкретный пример. И тот легко обходится. Тебе уже более одного раза мягко намекали, что твой подход крайне непрофессионален.
G>>Чукча не читатель? IB>Я уже вижу кто здесь чукча — тебе уже и разжевали все, и примеры привели, и сами разработчики написали, что "фигня у нас получилась, заново делать будем", а ты все твердишь, что инструмент идеален... Расслабься уже, все у тебя есть.
Я же говорю не читатель (или только читатель пресс-релизов). EF последовательно развивался с 2009 года, было 4 мажорных релиза и около 10 минорных. Никто не думал о переписывании, пока не появилось два кейса примерно в одно и тоже время — KRuntime и SQLite на Windows 8. На обоих EF не работает, просто исторически так сложилось, никогда не было целью обеспечить работу EF на мини-фреймворках. Поэтому собрались переписать.
Кстати из-за KRuntime еще и asp.net переписали, что же ты не рассказываешь всем что он сдох?
Здравствуйте, 80LevelElf, Вы писали:
LE>Так же я бы на вашем месте присмотрелся бы к https://github.com/igor-tkachev/bltoolkit . LE>Сам не работал(только собираюсь), но судя по всему очень крутая вещь. Ну и как минимум комьюнити не далеко(в соседней ветке форума ).
Лучше сразу использовать linq2db.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, vmpire, Вы писали:
V>Поэтому в процедурах используется некоторое количество временных таблиц, вставок в них, индексов и даже местами dynamic sql.
linq2db поддерживает DDL операции, в том числе создание (временных) таблиц. Всё это мы с успехом используем в своём проекте и прекрасно обходимся без сохранённых процедур.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, Нахлобуч, Вы писали:
Н>Нынешний уровень аргументации -- не канает, увы.
Конечно, хотелось бы большую аргументированную статью с примерами, кусками исходного кода с косяками самой библиотеки, фотографиями убитых проектов и видео со свидетельствами беженцев от EF... Так, стоп, это же вроде не Политика... Ну ты понял. Но, чтобы этим заниматься, нужно действительно очень ненавидеть EF и страстно хотеть его удушить. Видимо у Вани до этого не дошло и никаких фотографий убитых проектов у него нет, просто потому, что он вовремя отказался от EF.
С другой стороны, чтобы ты не говорил про "аргументация страдает", но сегодня сами разработчики признали EF ущербной библиотекой и собираются его переписывать с нуля. Ещё раз. Сами разработчики признали EF ущербной библиотекой и собираются его переписывать с нуля. Ваня же об этом говорит уже несколько лет. Думаю, это заслуживает внимания и уважения.
Если нам не помогут, то мы тоже никого не пощадим.
Re[19]: Почему вы НЕ используете Entity Framework?
Здравствуйте, gandjustas, Вы писали:
G>Это женская логика.
Сначала ты везде кричал, что они все поправили и SQL генерится самый лучший на свете. Я тебе показал, что это не так, но ты продолжаешь утверждать, что это фигня. Я тебе объяснил, что это косяк в архитектуре, а не просто ошибка, разработчики подтвердили тебе, что это by design, но ты все равно голову куда-то засовываешь. Вот это — женская логика.
G> Единичный пример не показывает ничего "в принципе". Также как единичный баг не говорит о качестве приложения "в принципе".
Еще один пример женской логики и неумения видеть проблему в целом.
Если единичный баг — системный и его нельзя поправить на протяжении нескольких лет потому что by design, то это таки говорит о качестве и архитектуре приложения "в принципе".
G> Тебе уже более одного раза мягко намекали, что твой подход крайне непрофессионален.
Душа моя, не тебе рассказывать мне про мою профессиональность. Мне глубоко не интересно, что думает о моей профессиональности человек, который не может вести диалог без перехода на личности и уж совсем не интересно собирать для него доказательную базу, если он очевидных примеров под носом не видит.
G> EF последовательно развивался с 2009 года, было 4 мажорных релиза и около 10 минорных.
Не с 2009, а с 2003 и не уверен, что эпитет "последовательно" здесь применим.
G> Никто не думал о переписывании, пока не появилось два кейса примерно в одно и тоже время — KRuntime и SQLite на Windows 8. На обоих EF не работает, просто исторически так сложилось, никогда не было целью обеспечить работу EF на мини-фреймворках. Поэтому собрались переписать.
И все таки — научись читать пресс-релизы. В жизни пригодится. Как минимум может помочь вовремя сбегать с мертвых технологий.
Снова цитирую реальные причины отказа от EF, а то ты похоже уже забыл или не дочитал:
we’ve had to take a realistic look at our current code base.
the code base is monolithic in nature which makes it difficult to implement new features and increasingly harder to change things without breaking existing functionality.
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. We also have a number of unintuitive behaviors that are engrained into the framework and hard to change or remove for the same reasons.
А, и мое любимое, к вопросу об изначально неправильной идеологии, которая лежит в основе EF и до сих пор торчит изо всех мест:
When Entity Framework began life, it’s charter was more to do with the Entity Data Model vision rather than being a best-of-breed O/RM.
Здравствуйте, Аноним, Вы писали:
А>Проект в котором важна скорость обработки данных в СУБД. Избавится от использования хранимых процедур в таких проектах невозможно, иначе придется большие объемы данных тащить в приложение и потом обратно с базой их "джойнить",
Это неверное утверждение.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, vmpire, Вы писали:
IT>>linq2db поддерживает DDL операции, в том числе создание (временных) таблиц. V>Если не секрет, как?
Своим собственным расширением. Создаётся таблица вызовом метода CreateTable, возвращается IQueriable объект, который дальше можно использовать в Linq как обычно. Также в наличии DML операции, соответственно новую таблицу можно заполнить данными на серверной стороне и использовать её в более сложных запросах.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, IT, Вы писали:
IT>Здравствуйте, 80LevelElf, Вы писали:
LE>>Так же я бы на вашем месте присмотрелся бы к https://github.com/igor-tkachev/bltoolkit . LE>>Сам не работал(только собираюсь), но судя по всему очень крутая вещь. Ну и как минимум комьюнити не далеко(в соседней ветке форума ).
IT>Лучше сразу использовать linq2db.
Игорь тысячу раз говорили что что бы его начать использовать в серьёзных проектах должен быть соответствующий уровень поддержки.
Если не платный продукт то хотя бы вариант платной поддержки.
Я вот даже если хочу не смогу его пропихнуть черехз наших legals-ов и прочих товарисчей.
Здравствуйте, IT, Вы писали:
IT>Здравствуйте, vmpire, Вы писали:
IT>>>linq2db поддерживает DDL операции, в том числе создание (временных) таблиц. V>>Если не секрет, как?
IT>Своим собственным расширением. Создаётся таблица вызовом метода CreateTable, возвращается IQueriable объект, который дальше можно использовать в Linq как обычно. Также в наличии DML операции, соответственно новую таблицу можно заполнить данными на серверной стороне и использовать её в более сложных запросах.
Здравствуйте, Tom, Вы писали:
Tom>Главный вопрос не как, а зачем
При использовании сохранённых процедур это весьма распространённая практика. Поэтому, для облегчения переноса кода на linq такое дело может облегчить задачу. Ещё полезно для очень тяжёлых запросов с пейджингом, требующих кроме самих данных ещё и count. Тогда закатываем данные во временную таблицу, получаем count, а затем возаращаем нужную страницу. Извратство, знаю, но бывает полезно.
Сам я стараюсь обходиться без временных таблиц.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, Tom, Вы писали:
Tom>Игорь тысячу раз говорили что что бы его начать использовать в серьёзных проектах должен быть соответствующий уровень поддержки. Tom>Если не платный продукт то хотя бы вариант платной поддержки.
Гусары денег с юзеров не берут.
Если нам не помогут, то мы тоже никого не пощадим.
Re[20]: Почему вы НЕ используете Entity Framework?
Здравствуйте, IB, Вы писали:
IB>Здравствуйте, gandjustas, Вы писали:
G>>Это женская логика. IB>Сначала ты везде кричал, что они все поправили и SQL генерится самый лучший на свете. Я тебе показал, что это не так, но ты продолжаешь утверждать, что это фигня. Я тебе объяснил, что это косяк в архитектуре, а не просто ошибка, разработчики подтвердили тебе, что это by design, но ты все равно голову куда-то засовываешь. Вот это — женская логика.
Откровенное вранье.
1) Я не утверждал что в EF "SQL генерится самый лучший на свете", я говорил что в совокупности покачто нет ничего лучше.
2) Ты показал ровно один баг, который легко обходится. На "косяк в архитектуре" один баг не тянет.
3) "разработчики подтвердили тебе, что это by design" — вранье
G>> Единичный пример не показывает ничего "в принципе". Также как единичный баг не говорит о качестве приложения "в принципе". IB>Еще один пример женской логики и неумения видеть проблему в целом.
Суждение "в целом" по одному косяку — пример женской логики.
IB>Если единичный баг — системный и его нельзя поправить на протяжении нескольких лет потому что by design, то это таки говорит о качестве и архитектуре приложения "в принципе".
С чего ты взял что он системный? Это лишь твои домыслы.
G>> Тебе уже более одного раза мягко намекали, что твой подход крайне непрофессионален. IB>Душа моя, не тебе рассказывать мне про мою профессиональность. Мне глубоко не интересно, что думает о моей профессиональности человек, который не может вести диалог без перехода на личности и уж совсем не интересно собирать для него доказательную базу, если он очевидных примеров под носом не видит.
Какие "очевидные примеры"? Ты показал один. В любом ORM найдется как минимум один баг.
G>> EF последовательно развивался с 2009 года, было 4 мажорных релиза и около 10 минорных. IB>Не с 2009, а с 2003 и не уверен, что эпитет "последовательно" здесь применим.
Да хоть с рождения христа, какая разница? Реально EF стал юзабелен с версии 5, то есть два года назад. Но видимо ты его видел крайний раз в том самом 2003 году.
G>> Никто не думал о переписывании, пока не появилось два кейса примерно в одно и тоже время — KRuntime и SQLite на Windows 8. На обоих EF не работает, просто исторически так сложилось, никогда не было целью обеспечить работу EF на мини-фреймворках. Поэтому собрались переписать. IB>И все таки — научись читать пресс-релизы. В жизни пригодится. Как минимум может помочь вовремя сбегать с мертвых технологий. IB>Снова цитирую реальные причины отказа от EF, а то ты похоже уже забыл или не дочитал: IB>we’ve had to take a realistic look at our current code base. IB>the code base is monolithic in nature which makes it difficult to implement new features and increasingly harder to change things without breaking existing functionality. IB>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. We also have a number of unintuitive behaviors that are engrained into the framework and hard to change or remove for the same reasons.
IB>А, и мое любимое, к вопросу об изначально неправильной идеологии, которая лежит в основе EF и до сих пор торчит изо всех мест: IB>When Entity Framework began life, it’s charter was more to do with the Entity Data Model vision rather than being a best-of-breed O/RM.
Я слишком хорошо знаю как работает маркетинг МС, чтобы не верить ни одному пресс-релизу. Поэтому я читаю код вместо маркетингового буллшита.
Здравствуйте, IT, Вы писали:
IT>Здравствуйте, vmpire, Вы писали:
IT>>>linq2db поддерживает DDL операции, в том числе создание (временных) таблиц. V>>Если не секрет, как?
IT>Своим собственным расширением. Создаётся таблица вызовом метода CreateTable, возвращается IQueriable объект, который дальше можно использовать в Linq как обычно. Также в наличии DML операции, соответственно новую таблицу можно заполнить данными на серверной стороне и использовать её в более сложных запросах.
Я был бы рад увидеть примеры применения всех возможностей linq2db. Кривая изучения с помощью исходников слишком кривая для реального применения.
Здравствуйте, gandjustas, Вы писали:
G>Я был бы рад увидеть примеры применения всех возможностей linq2db. Кривая изучения с помощью исходников слишком кривая для реального применения.
С чего начать?
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, IT, Вы писали:
IT>Здравствуйте, gandjustas, Вы писали:
G>>Я был бы рад увидеть примеры применения всех возможностей linq2db. Кривая изучения с помощью исходников слишком кривая для реального применения.
IT>С чего начать?
1) пошаговый гайд подключения к проекту с разными субд
2) описание мэппинга, ключи, коллекции, nullable
3) построение сложных linq запросов, декомпозиция, функции, fts, как сделать fulljoin итп
4) пример приложения, взять готовый mvc music store и переписать на linq2db
5) пошаговый гайд по миграции с рукопашных запросов на linq2db
6) описание фишек для временных таблиц и чего там еще есть
Здравствуйте, IT, Вы писали:
IT>Здравствуйте, Tom, Вы писали:
Tom>>Игорь тысячу раз говорили что что бы его начать использовать в серьёзных проектах должен быть соответствующий уровень поддержки. Tom>>Если не платный продукт то хотя бы вариант платной поддержки.
IT>Гусары денег с юзеров не берут.
Вам дело советуют. Это же хороший продукт! Так поднимите с него денег. Тестерам дадите, или еще кому. Визуальный редактор, code-first и прочие удобства будут не лишними, но писать это — муторно. Пускай это люди за деньги пишут.
Re[3]: Почему вы НЕ используете Entity Framework?
От:
Аноним
Дата:
12.07.14 14:26
Оценка:
Здравствуйте, Artem Korneev, Вы писали:
AK>Здравствуйте, Аноним, Вы писали:
AK>>>Какие ещё минусы есть у Entity Framework? Что может послужить аргументом для отказа от его использования в проекте? А>>Проект в котором важна скорость обработки данных в СУБД. Избавится от использования хранимых процедур в таких проектах невозможно, иначе придется большие объемы данных тащить в приложение и потом обратно с базой их "джойнить", это всегда эффективнее делать на уровне СУБД.
AK>Насколько я помню, EntityFramework не гоняет данные туда-сюда без нужды. Оно генерирует SQL-запрос и все данные обрабатываются на стороне сервера, т.е. из C# кода вы можете делать с данными почти тоже самое, что и через прямой SQL. AK>Пересылать данные на сторону сервера приложений оно начинает только тогда, когда Вы эти данные вытаскиваете из IQueryable и начинаете обрабатывать построчно C# кодом. Но это уже вполне логично, это уже выходит за рамки SQL-кода вообще и хранимых процедур в частности.
Нет волшебных запросов, т.е. на практике при обработке данных бывает сложно всю обработку в один запрос уместить и нужно сначала пройтись по результататм одного запроса, на базе этих данных или по условиям сформировать дополнительные запросы.
Если эту логику делать на уровне приложения то придется вытащить данные первого запроса ( а их может быть немало ), потом обработать и вытащить еще часть данных в общем получается много данных по сети приходится гонять.
Re[3]: Почему вы НЕ используете Entity Framework?
От:
Аноним
Дата:
12.07.14 14:35
Оценка:
Здравствуйте, IT, Вы писали:
IT>Здравствуйте, Аноним, Вы писали:
А>>Проект в котором важна скорость обработки данных в СУБД. Избавится от использования хранимых процедур в таких проектах невозможно, иначе придется большие объемы данных тащить в приложение и потом обратно с базой их "джойнить",
IT>Это неверное утверждение.
Обоснуйте.
На практике нет возможности все действо в 1м запросе сделать. Иногда требуется выполнить запрос1 и его данные как правило не нужны, требуется его постобработка и только тогда уже нужные данные получаются.
Если не верите почитайте зачем временные таблицы нужны например.
Re[20]: Почему вы НЕ используете Entity Framework?
IB>И все таки — научись читать пресс-релизы. В жизни пригодится. Как минимум может помочь вовремя сбегать с мертвых технологий. IB>Снова цитирую реальные причины отказа от EF, а то ты похоже уже забыл или не дочитал: IB>we’ve had to take a realistic look at our current code base. IB>the code base is monolithic in nature which makes it difficult to implement new features and increasingly harder to change things without breaking existing functionality. IB>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. We also have a number of unintuitive behaviors that are engrained into the framework and hard to change or remove for the same reasons.
А вас не пугает в EF7 вот это:
EF7 Enables New Data Stores
While parts of Entity Framework are clearly tied to relational data stores, much of the functionality that EF provides is applicable to many non-relational data stores too. Examples of such functionality include change tracking, LINQ, and unit of work. In EF7 we will be enabling providers that target non-relational data stores, such as Azure Table Storage.
We are explicitly not trying to build an abstraction layer that hides the type of data store you are targeting. The common patterns/components that apply to most data stores will be handled by the core framework. Things that are specific to particular types of data stores will be available as extensions that are included as part of the provider. For example, the concept of a model builder that allows you to configure your model will be part of the core framework. However, the ability to configure things such as cascade delete on a foreign key constraint will be included as extensions in the relational database provider.
Все эти common patterns и extensions меня настораживают. Дьявол то в деталях, и то, что на поверхности выгляди как common, в деталях может оказаться совсем не common, или common часть совсем тривиальной.
Здравствуйте, Аноним, Вы писали:
А>На практике нет возможности все действо в 1м запросе сделать. Иногда требуется выполнить запрос1 и его данные как правило не нужны, требуется его постобработка и только тогда уже нужные данные получаются.
Всё так.
А>Если не верите почитайте зачем временные таблицы нужны например.
С временными таблицами можно легко работать без сохранённых процедур. В том числе на linq.
Если нам не помогут, то мы тоже никого не пощадим.
Re[5]: Почему вы НЕ используете Entity Framework?
От:
Аноним
Дата:
12.07.14 17:15
Оценка:
IT>С временными таблицами можно легко работать без сохранённых процедур. В том числе на linq.
При работе с пулом, .net дает гарантии что 2 запроса выполнятся в одной сессии ?
Здравствуйте, Аноним, Вы писали:
IT>>С временными таблицами можно легко работать без сохранённых процедур. В том числе на linq. А>При работе с пулом, .net дает гарантии что 2 запроса выполнятся в одной сессии ?
При чём тут пул? Открывается соединение, которое берётся из пула, затем на нём выполняются команды. Существует проблема с некоторыми драйверами типа DB2, которые после каждой команды выполняют комит и не дают возможности это действие отменить, в результате временные таблицы, живущие до комита недоступны следующей команде. Но это всё мелочи и с этим можно бороться. А так всё работает шо железная железяка.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, Аноним, Вы писали:
А>Здравствуйте, Artem Korneev, Вы писали:
AK>>Здравствуйте, Аноним, Вы писали:
AK>>>>Какие ещё минусы есть у Entity Framework? Что может послужить аргументом для отказа от его использования в проекте? А>>>Проект в котором важна скорость обработки данных в СУБД. Избавится от использования хранимых процедур в таких проектах невозможно, иначе придется большие объемы данных тащить в приложение и потом обратно с базой их "джойнить", это всегда эффективнее делать на уровне СУБД.
AK>>Насколько я помню, EntityFramework не гоняет данные туда-сюда без нужды. Оно генерирует SQL-запрос и все данные обрабатываются на стороне сервера, т.е. из C# кода вы можете делать с данными почти тоже самое, что и через прямой SQL. AK>>Пересылать данные на сторону сервера приложений оно начинает только тогда, когда Вы эти данные вытаскиваете из IQueryable и начинаете обрабатывать построчно C# кодом. Но это уже вполне логично, это уже выходит за рамки SQL-кода вообще и хранимых процедур в частности.
А>Нет волшебных запросов, т.е. на практике при обработке данных бывает сложно всю обработку в один запрос уместить и нужно сначала пройтись по результататм одного запроса, на базе этих данных или по условиям сформировать дополнительные запросы.
Подзапросы отменили? Вообще с использованием CTE запрос select является полным по тьюрингу, то есть абсолютно любую выборку можно сделать ровно одним селектом.
Так как в insert\update\delete можно использовать результаты select запроса, то в принципе можно сделать все.
Конечно упирается все в выразительную силу SQL и способность приложения генерировать такие запросы. Но на практике в среднем приложении довольно сложно придумать запрос, который обязательно надо сделать внутри процедуры, а не просто батчем.
Здравствуйте, IT, Вы писали:
IT>Здравствуйте, gandjustas, Вы писали:
G>>Я был бы рад увидеть примеры применения всех возможностей linq2db. Кривая изучения с помощью исходников слишком кривая для реального применения.
IT>С чего начать?
С продвинутых техник. База вроде как тут есть.
Например понять, что к чему в этом я не могу.
Вообще интересуют возможности по встраиванию БД-специфичных штук в линк провайдер. По тем же кастомным агрегатным функциям несколько раз уже вопрос поднимался на форуме.
Здравствуйте, Tom, Вы писали:
IT>>Лучше сразу использовать linq2db. Tom>Игорь тысячу раз говорили что что бы его начать использовать в серьёзных проектах должен быть соответствующий уровень поддержки.
И какой у EF6+ уровень поддержки? Проект на codeplex как открыли так и закрыть можно.
Если у Вас нет паранойи, то это еще не значит, что они за Вами не следят.
TK>И какой у EF6+ уровень поддержки? Проект на codeplex как открыли так и закрыть можно.
Если у тебя есть подписка MSDN и срочный case то им можно возпользоваться и зпэскалэйтить в MS, и при надобности фикс сделают только для тебя лично...
Здравствуйте, Tom, Вы писали:
TK>>И какой у EF6+ уровень поддержки? Проект на codeplex как открыли так и закрыть можно. Tom>Если у тебя есть подписка MSDN и срочный case то им можно возпользоваться и зпэскалэйтить в MS, и при надобности фикс сделают только для тебя лично...
Подписка на MSDN и фикс какого-то там проекта на codeplex который даже не часть .net framework? Может еще и для ночных билдов? Я умоляю...
Решить проблему с авторами linq2db будет сильно проще (как и включить фикс в основную ветку)...
Если у Вас нет паранойи, то это еще не значит, что они за Вами не следят.
TK>Подписка на MSDN и фикс какого-то там проекта на codeplex который даже не часть .net framework? Может еще и для ночных билдов? Я умоляю... TK>Решить проблему с авторами linq2db будет сильно проще (как и включить фикс в основную ветку)...
Я видимо не понятно описалл проблему, за EF есть большая компания которая официально поддерживает и развивает EF.
Соответственно если мы инвестируем свои деньги в использованием EF мы имеем хорошую гарантию что проект не свернут завтра по какой либо причине.
Когда библиотека делается на коленке одним разработчиком, у нас нет никаких гарантий поддержки и развития продукта.
Не дай бог чего с кем случиться — что будет с проектом...
И даже если я лично верю в то что библиотека хорошая то буз большой комьюнити и хорошей поддержки убедить начальство её использовать для нашего проекта невозможно.
Для нас в идеале было бы если бы за проектом стояла бы какая то официальная компания с которой можно было бы заключить офиц. договор и даже заплатить за проект и его поддержку бабло.
Здравствуйте, Tom, Вы писали:
Tom>Я видимо не понятно описалл проблему, за EF есть большая компания которая официально поддерживает и развивает EF.
Эта компания закрывает разработку одной технологии за другой с удивительной последовательностью. Сначала прекратилась разработка Linq2SQL, теперь прекращается работа над текущей версией EF. Что они породят на этот раз и сколько это продержится можно только гадать. Тем не менее, компания ведь большая и ей можно верить, ага
Tom>Когда библиотека делается на коленке одним разработчиком, у нас нет никаких гарантий поддержки и развития продукта.
Понятное дело. Библитека живёт и развивается уже почти 12 лет без всяких гарантий. Какие тут могут быть гарантии?
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, Tom, Вы писали:
Tom>Я видимо не понятно описалл проблему, за EF есть большая компания которая официально поддерживает и развивает EF. Tom>Соответственно если мы инвестируем свои деньги в использованием EF мы имеем хорошую гарантию что проект не свернут завтра по какой либо причине. Tom>Когда библиотека делается на коленке одним разработчиком, у нас нет никаких гарантий поддержки и развития продукта.
Ню-ню, у меня сейчас 2 направления бизнеса склеивают ласты по причине хорошей поддержке технологии Сильверлайт большой компанией.
И это при том, что Микрософт остается самым вменяемым партнером из всех больших корпораций.
Интересно. Не знал про эту фичу SQL.
А как "навесить хинты" через EF?
G>То есть способ не писать left join руками в Linq. G>Так вот в EF появляется дополнительно вычисляемое поле, по которому потом идет сортировка.
А если left join написан руками, то проблем нет? То есть, всё решение заключается в избегании такого неявного JOIN, или там ещё что-то нужно?
AK>>А какие именно возможности SQL нельзя использовать через EF? G>Например в linq нельзя написать MERGE оператор, использовать output выражения, табличные параметры для функций, FullTextSearch, ranking функции pivot\untivot и много чего еще. Большую часть можно обойти изобретением своих функий, но иногда проще тупо SQL написать.
А есть где-нибудь вот эта информация в сводном виде? Или какие-то исходные данные, из которых можно вывести таблицу — какие возможности SQL поддерживаются в EF, а какие не поддерживаются? У нас многое из перечисленного активно используется — и ranking-функции, и pivot, и merge, и табличные параметры. Мне надо бы рассказать команде про эти вещи и про обходные пути до миграции на EF. Да и самому нужно оценить целесообразность полной миграции — данных у нас очень уж много, некоторые операции по обработке данных длятся по нескольку часов. А такие вещи как MERGE, улучшают производительность (1 операция ввода/вывода вместо двух на SELECT + INSERT/UPDATE), так что часть обработки данных придётся оставить в хранимых процедурах до лучших времён.
Здравствуйте, Artem Korneev, Вы писали:
AK>Здравствуйте, gandjustas, Вы писали:
G>>>>1) нельзя навесить хинты. Это вообще-то не правда, но люди упорно повторяют эту глупость. AK>>>А "хинт" это что? G>>http://msdn.microsoft.com/en-us/library/ms187713.aspx
AK>Интересно. Не знал про эту фичу SQL. AK>А как "навесить хинты" через EF?
Через EF никак, а создать plan guide на сервере — легко.
G>>То есть способ не писать left join руками в Linq. G>>Так вот в EF появляется дополнительно вычисляемое поле, по которому потом идет сортировка.
AK>А если left join написан руками, то проблем нет? То есть, всё решение заключается в избегании такого неявного JOIN, или там ещё что-то нужно?
Да. Одно исключение — неявный джоин нужен когда надо чтобы ChangeTracking работал.
AK>>>А какие именно возможности SQL нельзя использовать через EF? G>>Например в linq нельзя написать MERGE оператор, использовать output выражения, табличные параметры для функций, FullTextSearch, ranking функции pivot\untivot и много чего еще. Большую часть можно обойти изобретением своих функий, но иногда проще тупо SQL написать.
AK>А есть где-нибудь вот эта информация в сводном виде? Или какие-то исходные данные, из которых можно вывести таблицу — какие возможности SQL поддерживаются в EF, а какие не поддерживаются? У нас многое из перечисленного активно используется — и ranking-функции, и pivot, и merge, и табличные параметры. Мне надо бы рассказать команде про эти вещи и про обходные пути до миграции на EF. Да и самому нужно оценить целесообразность полной миграции — данных у нас очень уж много, некоторые операции по обработке данных длятся по нескольку часов. А такие вещи как MERGE, улучшают производительность (1 операция ввода/вывода вместо двух на SELECT + INSERT/UPDATE), так что часть обработки данных придётся оставить в хранимых процедурах до лучших времён.
Многие вещи можно завернуть во view\inline-функции на сервере. Тут надо смотреть что конкретно используется и как мигрировать. Я бы предложил Linq2DB использовать.
Для начала все равно надо обычные SqlCommand+ручной мэппинг переписать на вызовы ef\linq2db, потом заменить текстовые запросы на IQueryable по возможности, потом выстаскивать проекции и предикаты как можно выше по стеку вызовов. Там где не получится IQueryable, можно оставить как есть.
Здравствуйте, Tom, Вы писали:
TK>>Подписка на MSDN и фикс какого-то там проекта на codeplex который даже не часть .net framework? Может еще и для ночных билдов? Я умоляю... TK>>Решить проблему с авторами linq2db будет сильно проще (как и включить фикс в основную ветку)... Tom>Я видимо не понятно описалл проблему, за EF есть большая компания которая официально поддерживает и развивает EF. Tom>Соответственно если мы инвестируем свои деньги в использованием EF мы имеем хорошую гарантию что проект не свернут завтра по какой либо причине.
Практика показывает, что никакой гарантии нет. Передавайте привет силверлайту
Tom>Когда библиотека делается на коленке одним разработчиком, у нас нет никаких гарантий поддержки и развития продукта. Tom>Не дай бог чего с кем случиться — что будет с проектом...
Так надо брать не только бинарники но и исходники — один разработчик шибко много не напишет.
Если у Вас нет паранойи, то это еще не значит, что они за Вами не следят.
Здравствуйте, IB, Вы писали:
AK>> Переход на EF я рассматриваю как шанс избавиться от хранимых процедур вообще. IB>В принципе это вариант, но не надо использовать EF для этого, посмотрите на другие альтернативы.
У нас для использования любой сторонней библиотеки нужно получать благословение от начальства, так что пока пробую оценить целесообразность миграции именно на EF, так как он уже есть в списке доступных библиотек. Если минусов наберётся слишком уж много, то буду думать.
IB>Основная слабая сторона EF в том, что он насчитывает историю более десяти лет и все это время разработка этого инструмента базировалась на ошибочных представлениях об ORM. Последние несколько лет, они пытались исправить ситуацию, но хвосты торчат до сих пор и мешаются под ногами на каждом шагу. Все остальные частности — лишь следствие, но по факту получился редкостный уродец.
Меня конкретика интересует. Но немного конкретики я уже набрал — косяки при неявном использовании left join (но если с явным left join всё нормально, то это можно отнести к known bug и избегать неявных join'ов), отсутствие доступа к таким возможностям SQL как MERGE, pivot и т.п.
Да, это как-то не комильфо.
Там написано, что совместимость работы через DbContext сильно ломать не будут и миграция должна быть несложной, так что грядущее переписывание EF с нуля меня не сильно пугает -- сейчас есть EF6, который в общем и целом не так уж плох, а через пару лет появится EF7, который будет вообще прекрасен и можно будет на него мигрировать. Но вот из интересного — почитал я там про причины переписывания. Одна из причин там — поддержка SQLite, я так понимаю, SQLite обещается только в EF7? А сейчас SQLite не поддерживается чтоль? А то я планировал использовать SQLite для запуска юнит-тестов в памяти..
Здравствуйте, Sharov, Вы писали:
AK>> С тем, чтобы сначала использовать его для вызова имеющихся хранимых процедур и постепенно, по мере доработки кода, переписывать хранимые процедуры на LINQ-запросы. Ну это чтобы не ломать то, что есть и не тратить полгода на переписывание с нуля. S>Зачем,
Ну хотя бы потому, что если иметь всю бизнес-логику на стороне C#, то C#-разработчикам проще эту логику читать и отлаживать -- всё перед глазами, прямо в Visual Studio.
S>если вы тут в производительности потеряете? Кэширование плана, если это огромный запрос, то экономика трафика и т.д и т.п.
У нас мало запросов, но выполняются они очень долго. Передача огромного запроса — это несколько килобайт SQL-кода, это дело нескольких секунд. Выполняется же каждый запрос по несколько минут.
TK>Так надо брать не только бинарники но и исходники — один разработчик шибко много не напишет.
Если брать исходники, это значит в них разбираться. А если разбираться, то следующий вопрос, как с ними жить. Можно жить вместе с библиотекой и слать патчи с просьбой закомитить в основную ветку. А можно отделиться и фактически писать свой linq provider, поглядывая в имеющуюся реализацию. При этом в своих исходниках можно кое-что упростить, выкинув неактуальные вещи: поддержку десятков СУБД и т.д., дописать нужные твоему проекту вещи. Но в этом варианте ты не можешь автоматом получить того развития, которое идет в исходной библиотеке. Таким образом, “взять исходники” постепенно и незаметно выльется в ощутимые затраты времени разработчиков.
Когда берешь что-то массовое типа EF, то есть поддержка со стороны поисковой строки в google.com. Но есть проблемы с архитектурной кривизной EF.
Для себя я вижу выход в том, чтобы не уходить далеко от чистого ADO.NET. Не должно быть много исходников в библиотеке, которая обеспечивает доступ к СУБД.
Re[21]: Почему вы НЕ используете Entity Framework?
Здравствуйте, Alexander Polyakov, Вы писали:
AP>А вас не пугает в EF7 вот это:
Да пофиг. Как напишут — посмотрим что получится, а для текущих задач мне вполне хватает linq2SQL и linq2db.
Здравствуйте, Alexander Polyakov, Вы писали:
AK>>... мне уже приходилось писать подобие юнит-тестов для EF, где использовалась временная база данных на реальном SQL-сервере. Это работает, но медленно. AP>Насколько медленно, в миллисекундах сколько и на что тратится?
Сейчас я работаю над другим проектом, так что посмотреть уже не могу. Но больше всего времени там уходило на создание временной базы данных и на очистку данных между тестами (DELETE/TRUNCATE). Создание временных таблиц и ещё что-то в этом духе.
С уважением, Artem Korneev.
Re[2]: Потому что у нас и так все хорошо работает :)
Здравствуйте, rm822, Вы писали:
AK>>трудности написания юнит-тестов для хранимых процедур R>можно подумать есть принципиальная разница между тестированием ХП и кода на шарпе
Есть практическая разница. Отлаживать и покрывать юниттестами C# код сильно проще. По крайней мере, нашей команде.
AK>>Сейчас на legacy-проекте есть полтора разработчика, которые хорошо ориентируются в имеющихся SQL-процедурах R>Прекрасная новость, как мне кажется
Что именно? То, что на проекте всего полтора разработчика, которые могут за приемлемое время разобраться в имеющемся SQL-коде?
Немалая часть багов за последнее время всплывала именно в SQL-коде, который на данный момент не покрыт юнит-тестами вообще никак.
AK>>Какие ещё минусы есть у Entity Framework? Что может послужить аргументом для отказа от его использования в проекте? R>Минусы в использовании практически любой подобной хрени всегда одни и те же R>- слой хранимок/вьюх это слой абстракции отделяющий физическую структуру данных от интерфейса. При наличии dev-DBA он необходим
У нас это не слой абстракции, у нас туда уехала уже куча бизнес-логики. dev-DBA у нас нет.
R>- реализация BL вне хранимок создает лишний трафик, из-за передачи данных из сервера БД
Не создаёт. ORM работает с данными через динамически генерируемые SQL-запросы.
R>- реализация BL вне хранимок часто категорически неприемлема, если сервер БД _может_ находиться далеко (например издыхание сервера БД в основном ДЦ, и автоматический фэйловер к резервному, до которого пинг 70мс, азуры, амазоны, просто фиговый коннект в корпоративном интранете)
Хранимки от не-хранимок отличаются только передачей текста запроса -- в случае ORM запрос генерируется динамически и отправляется на сервер, где его ещё нужно распарсить и запустить. При использовании хранимых процедур -- текст уже там.
В моих сценариях эта разница несущественна, т.к. время отправки запроса в любом случае пренебрежимо мало по сравнению со временем выполнения этого запроса -- секунды против минут или даже десятков минут.
Ещё один минус Entity Framework — то, что он не умеет использовать некоторые возможности SQL -- merge, pivot и т.д. Вот это для нас уже более существенно. Будем думать.
С уважением, Artem Korneev.
Re[21]: Почему вы НЕ используете Entity Framework?
Здравствуйте, gandjustas, Вы писали:
G>1) Я не утверждал что в EF "SQL генерится самый лучший на свете", я говорил что в совокупности покачто нет ничего лучше.
Вот тут самое время опять вспомнить про женскую логику — можешь объяснить разницу между "самый лучший на свете" и "в совокупности нет ничего лучше"?
G>2) Ты показал ровно один баг, который легко обходится. На "косяк в архитектуре" один баг не тянет.
Я тебе этот баг не просто показал. Я тебе его предсказал основываясь на знании архитектуры EF, таким образом — этот баг лишь следствие особенностей архитектуры, а не просто ошибка которую не заметили.
G>С чего ты взял что он системный? Это лишь твои домыслы.
Как можно заметить — мои домыслы часто оказываются очень верными. Я тебе даже объяснил на чем эти домыслы основаны Однако я полностью признаю за тобой право продолжать считать это лишь домыслами. ))
G>Я слишком хорошо знаю как работает маркетинг МС, чтобы не верить ни одному пресс-релизу.
Тут видишь ли какое дело. Если маркетинг МС говорит, что за какой-то технологией будущее, то действительно, фиг его знает как оно на самом деле... Однако если он говорит, что на какую-то технологию компания кладет болт — то еще не было примеров того, чтобы эту технологию потом продолжали развивать.
Так что если ты действительно хорошо знаешь маркетинг МС, то с EF ситуация намного хуже того, что написано в этом пресс-релизе. На очень много хуже.
G>Поэтому я читаю код вместо маркетингового буллшита.
Похоже, что и код читать у меня пока получается лучше чем у тебя
Здравствуйте, Artem Korneev, Вы писали:
AK>У нас для использования любой сторонней библиотеки нужно получать благословение от начальства, так что пока пробую оценить целесообразность миграции именно на EF, так как он уже есть в списке доступных библиотек. Если минусов наберётся слишком уж много, то буду думать.
Тогда лучше брать linq2SQL — с ним точно ничего не будет, так как он часть фреймворка. Его достоинство в том, что он простой как рельс, его функциональности хватает процентов на 90 задач и на нем просто невозможно написать неправильно. Чуть больше ручной работы, зато все происходит явно и прозрачно, и очень низкий порог вхождения.
Потом можно будет довольно просто перейти на любой linq ORM, если вдруг его функционала окажется недостаточно.
AK>Меня конкретика интересует. Но немного конкретики я уже набрал — косяки при неявном использовании left join (но если с явным left join всё нормально, то это можно отнести к known bug и избегать неявных join'ов),
Так как проблема системная, то прежде чем вы сможете действительно уверенно писать с использованием EF избегая всех скользких моментов — придется вложить довольно много усилий в освоение этого продукта. А потом эти знания окажутся бесполезными, как только они его все-таки перепишут.
Есть конечно вариант забить на все это и писать лишь бы работало, дождаться EF7 и оптимизировать уже под него, но это уж вам решать.
AK>Одна из причин там — поддержка SQLite, я так понимаю, SQLite обещается только в EF7? А сейчас SQLite не поддерживается чтоль?
Поддерживается, но не очень стабильно
However, that I have decided that SQLite is not a good fit for the Entity Framework, as too many critical functions are missing. I switched over to SQL Server Compact Edition, which I installed via NuGet. A simple tweak to my Connection String and I was running with the full power of Entity Framework. It took less than a minute, compared to the multi-hour slog that was SQLite. I'd recommend switching databases if possible, System.Data.SQLite just isn't ready for the Entity Framework.
Мы уже победили, просто это еще не так заметно...
Re[22]: Почему вы НЕ используете Entity Framework?
Здравствуйте, IB, Вы писали:
IB>Здравствуйте, gandjustas, Вы писали:
G>>1) Я не утверждал что в EF "SQL генерится самый лучший на свете", я говорил что в совокупности покачто нет ничего лучше. IB>Вот тут самое время опять вспомнить про женскую логику — можешь объяснить разницу между "самый лучший на свете" и "в совокупности нет ничего лучше"?
В совокупности нет лучше не говорит о том, что ef будет лучше в каждом конкретном случае.
Например для миграции legacy кода, работающего через SqlCommand гораздо лучше подойдет Linq2db
G>>2) Ты показал ровно один баг, который легко обходится. На "косяк в архитектуре" один баг не тянет. IB>Я тебе этот баг не просто показал. Я тебе его предсказал основываясь на знании архитектуры EF, таким образом — этот баг лишь следствие особенностей архитектуры, а не просто ошибка которую не заметили.
Все равно это один баг
G>>Я слишком хорошо знаю как работает маркетинг МС, чтобы не верить ни одному пресс-релизу. IB>Тут видишь ли какое дело. Если маркетинг МС говорит, что за какой-то технологией будущее, то действительно, фиг его знает как оно на самом деле... Однако если он говорит, что на какую-то технологию компания кладет болт — то еще не было примеров того, чтобы эту технологию потом продолжали развивать. IB>Так что если ты действительно хорошо знаешь маркетинг МС, то с EF ситуация намного хуже того, что написано в этом пресс-релизе. На очень много хуже.
Включай голову:
1) За последние 3 года ситуация с EF не менялась. В версии 5 написали обертку вокруг ObjectContext, в версии 6 её значительно переписали, почему нельзя было также сделать в версии 7?
2) Совершенно случайно планы по переписыванию EF совпали с изобретением KRuntime и появлением SQLite на windows 8. И совершенно случайно EF на них не заработал.
3) Также случайно переписывание EF совпало с идеей продвижения W8 в enterprise и развитием и развитием ASP.NET в сторону универсальности (напомню что EF — часть asp.net)
Получается что переписывание вызвано вовсе не проблемами в EF (они за три года не поменялись), а только необходимостью работы под новыми платформами и новыми базами).
Также многократно замечено что маркетинг МС готов называть черное белым, а белое черным для реализации стратегии продвижения. Достаточно вспомнить что каждая вторая версия windows позиционируется как нечто революционное, написанное с нуля, хотя по факту является доработкой предыдущей версии до ума.
А лично у меня есть пример потрясающего маркетинга SharePoint, который уже два года рассказывает что server-side код это зло и срочно надо всем в облака, вот только облака закрывают от силы половину потребностей.
Вообще объявить предыдущую версию говном — в порядке вещей для MS. Почему-то это считается индульгенцией для любого, даже самого шандарахнутого плана. Причем не зависимо от реального качества предыдущей версии.
Здравствуйте, TK, Вы писали:
TK>Практика показывает, что никакой гарантии нет. Передавайте привет силверлайту
Вот-вот. Зубоскалить можно много, но вот умерший и закопаный Silverlight мейтейнится до сих пор. И аргументы, приведённые Tom-ом таки да, зачастую оказываются решающими: в подобном разговоре(внутри компании) мне вот прямо задали вопрос, что произойдёт с l2db если завтра на главного разработчика упадёт кирпич на улице, и я как-то затруднился описать перспективы. В отличии от аналогичной ситуации с l2e.
Собственно после этого тема "а давайте запилим на l2db" больше не поднималась.
Здравствуйте, IB, Вы писали:
AK>>Одна из причин там — поддержка SQLite, я так понимаю, SQLite обещается только в EF7? А сейчас SQLite не поддерживается чтоль? IB>Поддерживается, но не очень стабильно
Интересно, какие там могут быть сложности?
Если нам не помогут, то мы тоже никого не пощадим.
Re[3]: Потому что у нас и так все хорошо работает :)
R>>можно подумать есть принципиальная разница между тестированием ХП и кода на шарпе AK>Есть практическая разница. Отлаживать и покрывать юниттестами C# код сильно проще. По крайней мере, нашей команде.
А что именно у вас вызывает сложности (если отбросить "непривычно")?
AK>Что именно? То, что на проекте всего полтора разработчика, которые могут за приемлемое время разобраться в имеющемся SQL-коде?
Что 1.5 разработчика есть, это намного лучше чем 0
R>>- реализация BL вне хранимок создает лишний трафик, из-за передачи данных из сервера БД AK>Не создаёт. ORM работает с данными через динамически генерируемые SQL-запросы.
Вообще-то создает, и природа этого — неполная поддержка идиом SQLя.
Этот псевдо-код вы перепишете на выборку данных не во временную таблицу #t, а в приложение. AFAIK нет ведь поддержки временных таблиц в EF?
select ... into #t from ...
if exists(select ... from #t where ...)
exec proc1
if exists(select ... from #t where ...)
exec proc2
...
Re[4]: Потому что у нас и так все хорошо работает :)
Здравствуйте, rm822, Вы писали:
R>Этот псевдо-код вы перепишете на выборку данных не во временную таблицу #t, а в приложение. AFAIK нет ведь поддержки временных таблиц в EF? R>
R>select ... into #t from ...
R>if exists(select ... from #t where ...)
R> exec proc1
R>if exists(select ... from #t where ...)
R> exec proc2
R> ...
R>
И хорошо что нет, ибо данный код крайне неэффективен, особенно под нагрузкой.
Re[23]: Почему вы НЕ используете Entity Framework?
Здравствуйте, gandjustas, Вы писали:
G>Включай голову:
Ну попробуй уже хоть раз воспользоваться собственным советом
G>1) За последние 3 года ситуация с EF не менялась. В версии 5 написали обертку вокруг ObjectContext, в версии 6 её значительно переписали, почему нельзя было также сделать в версии 7?
Потому что нельзя уже бесконечно писать обертки над обертками — технический долг накапливается. В конце-концов, тебе же английским по белому написали почему — the code base is monolithic in nature which makes it difficult to implement new features and increasingly harder to change things without breaking existing functionality.
G>2) Совершенно случайно планы по переписыванию EF совпали с изобретением KRuntime и появлением SQLite на windows 8. И совершенно случайно EF на них не заработал. То есть ты утверждаешь, что архитектура EF столь прекрасна, что им проще переписать EF заново, чем просто сделать нормальный провайдер для SQLite? Ты хорошо понял в чью пользу этот аргумент?
G>3) Также случайно переписывание EF совпало с идеей продвижения W8 в enterprise и развитием и развитием ASP.NET в сторону универсальности (напомню что EF — часть asp.net)
Опять же, весь из себя энтерпрайзный EF оказался не способен работать в энтерпрайзе? И задуманный как супер универсальный, универсальность и не осилил? Какая прелесть.
То что он часть ASP.Net — отдельный прикол, надеюсь их не в месте со старой командой туда приписали.
G>Получается что переписывание вызвано вовсе не проблемами в EF (они за три года не поменялись), а только необходимостью работы под новыми платформами и новыми базами).
У тебя фантастическая способность выдавать желаемое за очень желаемое и путать теплое с мягким, точнее повод с причиной. То что ты перечислил — это формальный повод, а фиговый код и архитектура — это реальная причина.
Тот же Хэйлсберг очень долго порывался переписать компилятор шарпа и очень жаловался, что не дают, так как нету business reason. Собственно Roslyn и стал таким формальным поводом. Так и тут — EF, скорее всего, давно бы выкинули (я надеюсь, что до них сильно раньше дошло, что за чудо получилось), но налепить пару костылей поверх и присобачить модные фичи — сильно дешевле, чем привести продукт в божеский вид, вот и не разрешал никто. Хотя на мой взгляд — этого продукта вообще не должно было быть. Надо было придушить его еще в зародыше и развивать linq2sql.
G>Также многократно замечено что маркетинг МС готов называть черное белым, а белое черным для реализации стратегии продвижения. Достаточно вспомнить что каждая вторая версия windows позиционируется как нечто революционное, написанное с нуля, хотя по факту является доработкой предыдущей версии до ума. G>А лично у меня есть пример потрясающего маркетинга SharePoint, который уже два года рассказывает что server-side код это зло и срочно надо всем в облака, вот только облака закрывают от силы половину потребностей.
В огороде бузина, а в киеве дядька. Эти примеры совсем о другом.
G>Вообще объявить предыдущую версию говном — в порядке вещей для MS.
А вот это просто не правда. MS никогда, ни один свой продукт, даже уже закрытый, не признавал плохо написанным или криво сделанным. В сторону того же сирвелата никто и слова плохого не сказал. Они всегда очень аккуратно говорят о своем коде и своих продуктах, и отрицательные оценки позволяют давать только в личных разговорах и все равно очень осторожно.
Тот же шарповский компилятор или MVC — которые совсем не идеальны — хоть слово плохое от MS про них слышал? для web api они MVC буквально с нуля переписали, класс за классом, и ни одна сволочь не заикнулась, что в первый раз его ластоногие писали (хотя это так и было).
Здравствуйте, IT, Вы писали:
IT>Интересно, какие там могут быть сложности? Мне тоже любопытно было бы знать, что помешало просто реализовать нормальный провайдер.
Мы уже победили, просто это еще не так заметно...
Re[24]: Почему вы НЕ используете Entity Framework?
Здравствуйте, IB, Вы писали:
IB>Хотя на мой взгляд — этого продукта вообще не должно было быть. Надо было придушить его еще в зародыше и развивать linq2sql.
Кстати, да. Архитектурно код linq2sql вполне себе развиваем. Там по большому счёту только одна ошибка была сделана — парни изначально заложились только на одну БД — MS SQL Server. В результате многие решения оказались гвоздями прибитыми к этому семейству БД. На переделку не хватило времени, а потом занялись другими вещами. Но всё это ещё вполне реально поднять и начать развивать даже с сохранением существующего API.
Если нам не помогут, то мы тоже никого не пощадим.
Re[5]: Почему вы НЕ используете Entity Framework?
От:
Аноним
Дата:
15.07.14 16:41
Оценка:
Здравствуйте, gandjustas, Вы писали: G>По поводу запросов — только один кейс для EF, где он плохой запрос генерит, и то он элементрано обходится через ручной джоин.
Можно пример? Спасибо!
Здравствуйте, Аноним, Вы писали:
А>Здравствуйте, gandjustas, Вы писали: G>>По поводу запросов — только один кейс для EF, где он плохой запрос генерит, и то он элементрано обходится через ручной джоин. А>Можно пример? Спасибо!
Здравствуйте, IT, Вы писали:
IT>Здравствуйте, gandjustas, Вы писали:
G>>1) пошаговый гайд подключения к проекту с разными субд
IT>Вот такие ролики в качестве таких гайдов пойдут?
Супер, но текст тоже нужен чтобы гуглом находился и копипастить код можно было.
Здравствуйте, IT, Вы писали:
IT>Здравствуйте, gandjustas, Вы писали:
G>>1) пошаговый гайд подключения к проекту с разными субд
IT>Вот такие ролики в качестве таких гайдов пойдут?
Кстати хотелось бы видеть это все на примере веб-приложений, а не консольных.
Здравствуйте, IT, Вы писали:
G>>1) пошаговый гайд подключения к проекту с разными субд IT>Вот такие ролики в качестве таких гайдов пойдут?
Нужно добавить комментарии голосом. Только видео воспринимать трудно.
И убрать музыку, ибо на ютюбе копирасты лютуют. Могут забанить весь канал.
... << RSDN@Home 1.2.0 alpha 5 rev. 62>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[10]: Почему вы НЕ используете Entity Framework?
Здравствуйте, gandjustas, Вы писали:
G>Здравствуйте, IT, Вы писали:
IT>>Здравствуйте, gandjustas, Вы писали:
G>>>1) пошаговый гайд подключения к проекту с разными субд
IT>>Вот такие ролики в качестве таких гайдов пойдут? G>Супер, но текст тоже нужен чтобы гуглом находился и копипастить код можно было.
И побольше таких роликов бы.
В идеале короткие ролики каждый на свою тему а не одно 2=х часовое видео.
CRUD очень желательно показать.
Народная мудрось
всем все никому ничего(с).
Re[11]: Почему вы НЕ используете Entity Framework?
IT>http://youtu.be/m--oX73EGeQ IT>http://youtu.be/Qc-5UpMYQO0
впечатления от просмотра
-использование неюникодных строк это ахтунг, несерьезно, вызывает желание закрыть и дальше не смотреть
-использование scope_identity вместо Output inserted — примерно того же уровня
-выбор adhoc vs parameter крайне неочевиден, но что он есть — очень хорошо
-merge выглядит очень сложно
-поддержка DDL вообще никак не заинтересовала
Re[13]: Почему вы НЕ используете Entity Framework?
Здравствуйте, rm822, Вы писали:
R>-использование неюникодных строк это ахтунг, несерьезно, вызывает желание закрыть и дальше не смотреть
Юникодные строки к данному дему отношение имеют весьма опосредованное. При необходимости элементарно конфигурируются.
R>-использование scope_identity вместо Output inserted — примерно того же уровня
Не вижу принципиальной разницы, хотя сделать не сложно. Для DB2 используется похожий механизм. Кроме того, есть желание это расширить до полноценного output.
R>-выбор adhoc vs parameter крайне неочевиден, но что он есть — очень хорошо R>-merge выглядит очень сложно
Всмысле? Сложен Merge или InsertOrUpdate?
R>-поддержка DDL вообще никак не заинтересовала
DDL нужен в основном для работы с времеными таблицами. А так да, я лично предпочитаю база данных фёст.
Если нам не помогут, то мы тоже никого не пощадим.
Re[14]: Почему вы НЕ используете Entity Framework?
IT>Юникодные строки к данному дему отношение имеют весьма опосредованное.
Использование неюникодных строк — грубая ошибка, ваша дема тупо не будет работать на кириллице
наглядный пример
IT>Не вижу принципиальной разницы, хотя сделать не сложно.
вставьте 10 Записей с получением их идентити, так понятнее?
IT>Всмысле? Сложен Merge или InsertOrUpdate?
InsertOrUpdate этот пример вообще какой-то странный весь из себя
Очень странно что автоматом выбрано мердж on id, если я PK знаю на кой черт вообще нужен insertOrUpdate а не просто update?
Ну ладно, пускай будет ид, но зачем блин два раза тупл писать ? пока там 1,5 колонки это не проблема, но в реальности-то их будет штук 10
Проще должно быть, что-нибудь в духе
InsertOrUpdate( new TestTable { id =1, Name = "Bla-bla" } ).On( Id )
Re[15]: Почему вы НЕ используете Entity Framework?
Здравствуйте, rm822, Вы писали:
IT>>Юникодные строки к данному дему отношение имеют весьма опосредованное. R>Использование неюникодных строк — грубая ошибка, ваша дема тупо не будет работать на кириллице
Ещё раз. Моя дема не домонстрирует работу с юникодом вообще. Если нужна дема по демонстрации юникода, то её тоже можно сделать и продемонстрирвоать работу хоть с кирилицей, хоть с китаецей, хоть с японицей. Что касается грубости подобных ошибок как вообще, так и в частности, то это дело пользователя инструмента, а не самого инструмента. Молоток и плоскогубцы не должны учить мастера как и что он должен мастерить. Если инструмент навязывает пользователю обязательное использование юникода, то такому инструменту место на помойке.
IT>>Не вижу принципиальной разницы, хотя сделать не сложно. R>вставьте 10 Записей с получением их идентити, так понятнее?
В linq2db пока нет методов, позволяющих вставлять 10 записей с получением их identity. Когда такой метод появится, тогда output станет актуальным. А пока не вижу принципиальной разницы. Так понятней?
IT>>Всмысле? Сложен Merge или InsertOrUpdate? R>InsertOrUpdate этот пример вообще какой-то странный весь из себя R>Очень странно что автоматом выбрано мердж on id, если я PK знаю на кой черт вообще нужен insertOrUpdate а не просто update? R>Ну ладно, пускай будет ид, но зачем блин два раза тупл писать ? пока там 1,5 колонки это не проблема, но в реальности-то их будет штук 10
Потому что при Insert и Update может понадобиться разный набор колонок или разные значения. Впрочем, при желании можно написать overload с общим списком полей для Inser и Update и по списку по одтельности. Всё в наших руках.
R>Проще должно быть, что-нибудь в духе R> InsertOrUpdate( new TestTable { id =1, Name = "Bla-bla" } ).On( Id )
Это называется InsertOrReplace, есть в той же деме.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, Qodomoc, Вы писали:
Q>Очередные подробности про EF7. Похоже, что изменится реально много.
Если это главное что они собираются поменять в EF7, то как я и предполагал ранее, ребята явно сконцентрировались не на том. Правильный подход на самом деле может быть только один — Database First. Всё остальное годится исключиетльно для демок. В более менее серьёзных проектах остальные подходы не живут. Зато реализация этих подходов потребует серьёзных ресурсов, что приведёт к тому, что действительно нужные вещи будут задвинуты куда-ниубдь в угол, про них забудут, на них не хватит времени, опять прощёлкают их архитектуру и дизайн и опять всё поменяют в EF8.
В общем, ребятам нужно для начала годик поработать в Microsoft Consulting Services на реальных проектах клиентов с тотальным использованием EF, послушать маты в свой адрес и понять, что пора уже заканчивать заниматься фигней.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, IT, Вы писали:
IT>Здравствуйте, Qodomoc, Вы писали:
Q>>Очередные подробности про EF7. Похоже, что изменится реально много.
IT>Если это главное что они собираются поменять в EF7, то как я и предполагал ранее, ребята явно сконцентрировались не на том. Правильный подход на самом деле может быть только один — Database First. Всё остальное годится исключиетльно для демок. В более менее серьёзных проектах остальные подходы не живут. Зато реализация этих подходов потребует серьёзных ресурсов, что приведёт к тому, что действительно нужные вещи будут задвинуты куда-ниубдь в угол, про них забудут, на них не хватит времени, опять прощёлкают их архитектуру и дизайн и опять всё поменяют в EF8.
МС сейчас сконцентрирован на сайтиках и мобилках. Enterprise разработка, увы, не развивается вообще. Примерно за два года почти ничего не появилось для построения масштабных бизнес-систем.
Я узнавал почему так, ответ простой — это не продает облако.
Здравствуйте, IT, Вы писали:
IT>Если это главное что они собираются поменять в EF7, то как я и предполагал ранее, ребята явно сконцентрировались не на том.
Ну, рано загадывать на чем они сконцентрировались, пока это все дешевый популизм — пытаются успокоить недовольных переделками. Но вот пассаж про то что CodeFirst это вовсе не то, что мы имели ввиду — это красиво )
IT> нужные вещи будут задвинуты куда-ниубдь в угол, про них забудут, на них не хватит времени, опять прощёлкают их архитектуру и дизайн и опять всё поменяют в EF8.
Хорошо, если в EF8, чтобы осознать, что получилось фигня в прошлый раз, им понадобилось не меньше трех версий.
Здравствуйте, IT, Вы писали:
IT>Правильный подход на самом деле может быть только один — Database First.
Собственно в посте по ссылке и говорится, что Code First это Database First и Model First в одном лице.
rather than a third alternative to Database & Model First, Code First is really an alternative to the EDMX file format. Conceptually, Code First supports both the Database First and Model First workflows.
Причем, в таком варианте можно было его использовать еще с EF5 кажется. Были Reverse Engineering tools (хоть и бета но вполне работоспособные) для создания моделей и контекста по существующей БД.
IT>Всё остальное годится исключиетльно для демок.
Ну небольшие проекты (в стиле сайта для небольшой фирмы с каталогом) тоже вполне работоспособны и создаются быстрее на "классическом" CodeFirst. А вот чуть-чуть сложное и тут да, игнорировать возможности БД уже глупо, да и не всегда вообще получится.
).
Простой, надёжный, маленький и полностью контролируемый.
Мы уже победили, просто это еще не так заметно...
Если нам не помогут, то мы тоже никого не пощадим.
