http://codearticles.ru/articles/2409
http://codearticles.ru/articles/914
http://codearticles.ru/articles/422

Массовые операции, балк инсерты и тому подобное, немного выходит за рамки компетенции ORM. Хотя и она может решать такие задачи. Вопрос скорости зависит от объема данных, индексов и прочего. Где-то подойдет и обычный цикл с удалением entity.
P.S. В некоторых случаях не стоит в лоб решать задачу с помощью ORM, это и ежу понятно.

ПарамонEF это фактически DAL, но почему его кастрировали, не ясно.
Почему кастрировали? Возможность выполнить задачу есть. В чем вопрос?

ПарамонВыполнить красиво, одной командой, только в слое БЛ, а не гонять циклы и хардкодить запросы, не говоря уже про костыли и левые сборки.
Ну, вот одной командой. Вполне красиво и быстро.




ПарамонДобавляют, но медленно RemoveRange уже работает )
RemoveRange УГ, он транслирует 100500 команд. Во-вторых, если удаляемого ID нет (кто-то уже удалил), будет исключение. А в случае ExecuteStoreCommand никаких исключений.

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

ПарамонМСУНу, вот одной командой. Вполне красиво и быстро.




Тут мы все преимущества EF, а именно компайл тайм проверки, слили и унитаз.

МСУRemoveRange УГ, он транслирует 100500 команд. Во-вторых, если удаляемого ID нет (кто-то уже удалил), будет исключение. А в случае ExecuteStoreCommand никаких исключений.
Для небольших количеств - самое то.
1. Выше я дал рецепт, как можно использовать типизированный подход. Лично для меня оба варианта хороши.
2. Даже для одной записи - плохо. Т.к. в момент удаления ее может не быть. А это эксепшен.

ПарамонНет там никаких эксепшенов, о чем ты?
Ты вообще понял, про что я говорю?

Парамон, код в студию.

ПарамонМСУПарамон, код в студию.
Выше давал, один в один. Ты сам то пробовал или фантазируешь?
Учи матчасть, твой гавнокод никуда не годится. Зачем материализация, зачем предварительно селектировать, тем более SELECT * FORM? Прикинь, так блобы будут - ты сначале выберешь записи, а потом удалишь. Нужно делать через Attach, о чем выше писал хвост. Я думал, ты честно через Attach + RemoveRange делаешь.

Уж лучше context.Database.ExecuteSqlCommand юзать, чем такую жесть. Если нужна типизация: http://codearticles.ru/articles/914
Так это будет честное удаление без материализации.

ПарамонМСУНужно делать через Attach, о чем выше писал хвост.
Ага, я видел что он писал ))
Как ни странно, он абсолютно прав :)

ПарамонА в общем должно и с Attach работать, не могу сейчас проверить.
С Attach будет работать, как я уже писал. Но есть 2 тонкости. Трансляция в SQL будет одной командой sp_executesql + delete на одну запись, а не delete from where. Во-вторых, если при удалении записи её по какой-то случайности уже не стало, будет исключение. Таким образом, у тебя откатится вся транзакция и пакет не удалится.

ПарамонВот не нужно опять страшилки рассказывать, какой вменяемый человек вообще эти блобы в базу пихает )
А куда их пихать?

ПарамонКак я и сказал, прекрасно подходит для небольшого количества данных.
Да не подходит оно не куда. Гавно, а не решение.

ПарамонЗначит материализация нужна )
Ну значит загружай 100500 записей с блобами, а потом их удаляй.

ПарамонТоже самое транслирует и после селекта, и все ок.
Какого селекта?

ПарамонМСУА куда их пихать?

В папку )
Учи матчасть и читай рекомендации MS по хранению файлов :)

ПарамонМСУУчи матчасть и читай рекомендации MS по хранению файлов :)
Ничего интересного )
Читай их рекомендации по работе с EF, еще хуже ))
Говоришь загадками

hVosttпри работе с ORM, приходится полностью пересмотреть свои взгляды на работу с данными.
Глупости, ничего пересматривать не нужно. Более того, нужно понимать, во что транслируется тот или иной ef-запрос. И если выхлоп не совсем граничит с разумность, нужно вручную задать запрос и воспользоваться штатным маппером. Например, работа с деревьями. EF не умеет работать с CTE, увы. Но это не значит, что мне нужно пересматривать свои взгляды. Вот вариант http://codearticles.ru/articles/2147
Да, в данном случае мы потеряли типизацию, но это не так страшно в единичных случаях. Пусть 90% кода будет покрываться штатными возможностями ORM, остальное - специфика, от которой никуда не уйти. Это нормально.

hVosttгрохать сотнями тысяч записей одним запросом весьма типично для реляционной базы данных. но совершенно не типично для бизнес-логики.
Сотни тысяч - да, сотня - почему нет. Сегодня сотня, завтра тысяча. Я не вижу противоречий и не вижу реальной проблемы, исходя из которой разработчики EF забили на реализацию. Впрочем, на том же NHibernate можно написать честный hsql.

hVosttМСУГлупости, ничего пересматривать не нужно.
учитывая постоянно возникающие одни и те же вопросы — ещё как нужно.
У меня постоянно вопросы не возникают. Зачем мне это нужно? Проблема не в пересмотре, а в опыте. Если я вижу, что код ORM не оптимален, я использую штатные средства СУБД. А это примерно 10% всех манипуляций с БД, как видим ORM достаточно много покрывает рутинных работ.

hVosttМСУБолее того, нужно понимать, во что транслируется тот или иной ef-запрос.
Нет. Работать с ОРМ и заморачиваться с SQL — вочинка не стоит выделенки. При возникновении узких мест, профилирование и оптимизация, да. На уровне доступа к данным могут появится хардкоженные SQL-запросы. Но это уже показатель низкого качества архитектуры данных.
Да, и еще 10 раз да. Только полное понимание транслированного запроса. Бездумно писать ef-запросы ведет к деградации личности и непонимании принципов работы с БД. Хардкоженные запросы не так страшны, если они к месту. Некоторые их оборачивают вьюхами и хп, но это на любителя. ORM так или иначе используется.

hVosttМСУНапример, работа с деревьями. EF не умеет работать с CTE, увы.
Чёй-то? Создаётся СТЕ-вьюха, мапится на служебный DTO-класс, и получаем кристально чистую работу с деревьями без единой буквы SQL в коде.
Так это не работа EF с CTE, а работа EF с вьюхой. Это разные вещи. А реально бы хотелось трансляцию CTE, как это умеет делать NH. Да и объектов в БД будет меньше, это плюс.

МСУВот вариант http://codearticles.ru/articles/2147 Да, в данном случае мы потеряли типизацию, но это не так страшно в единичных случаях.

hVosttСм. выше. Никаких SqlQuery! Ничего мы не теряем, учимся грамотно использовать EF.
См. выше. Мне не нужны лишние объекты в БД. Да и не всегда вьюхой можно решить проблему и без функции / хп не обойтись. А нужно ли оно, другой вопрос.

hVosttМСУПусть 90% кода будет покрываться штатными возможностями ORM, остальное - специфика, от которой никуда не уйти.
Такая специфика существует. Но отнюдь не 10%. Может 1% не больше. Например Full Text Search и прочее вендорные плюшке.
Для хеллоуворлдов 1%, для реальных систем 10%. Есть куча специфичных запросов, когда без них не обойтись.

hVosttДавай так. Я приведу пару примеров, с решением без всяких SQL, а ты приведёшь приближённый к реальности пример задачи, где без SQL никак?
Ок.

hVosttПример 1. Про массовый DELETE. Существует биллинг с записями больше сотни тысяч в день. Существует задача подчистки записей старше 30 дней раз в конце деня (к примеру). Классический реляционный стиль: delete from blabla where dt > @lastDate ну или типо того. На EF без выкрутасов не выполнимо. Решение очевидное и простое. Таблица с днями биллинга, к каждой записи дня вяжется хоть милльён записей за этот день. Грохается одним элементарным Remove().
Сразу двойка. Никакими EF тут не пахнет, это чистой воды SSIS пакет (DTS, BizTalk оркестрарий и т.п.) на джобе. Воркфлоу отрабатывает биллинговые данные согласно оркестровки. Твой опыт в подобных задачах - как на ладони :)

hVosttПример 2. Про тяжёлые BLOB. В базе данных хранятся картинки, вместе с содержимым в блобах. Классический стиль -- запхать всё в одну таблицу и сидеть с довольной мордной. Правильно: блоб вывести в отдельную таблицу типа ImageContent. Преимущества: материализация записей с картинками не тянет за собой увесистые блобы, и кроме того запись картинки больше не зависит от способа хранения. ("виртуальность" в данных).
Вопросы хранения данных и архитектура хранилища никак не должны зависить от способов материализации чего-то там. EF у тебя или NH - это твои проблемы, архитектору и DB девелоперам по-барабану, как ты это будешь материализовывать. Ничего делить не нужно, не вижу сложностей в блобе конкретной таблицы. На EF просто не нужно его выбирать. И вообще, SELECT * FROM - это жутчайшее зло.

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

Где-то в степия в общем то согласен с хвостом, если не нормализованным архитекторам баз пофиг, ничего проще создать
составной тип, или блоб по запросу ( а ля отдельная таблица) не хочу что бы в кеше разный хлам таскался...
Вообще задача и выеденного яйца не стоит. Оба варианта приемлемы.

hVosttвидна как на ладони старая школа, по книгам 90-х годов
В старых школах не было упоминания про ORM, так что опять мимо, студент.

hVosttвыбирать поля при работе с ОРМ -- зло. объект он или целый, или никакой вообще. иного не дано. остальное моветон.
Ну вот чушь когда прекратишь писать? Серьезно, твои бредни читать невозможно...




Всё. А как ты потом это вмапишь в объекты - базу не колышит. А вмапить можно 100500 способами. Учи матчасть, знакок ORM мля...

hVosttппц. я те про фому, ты мне по ерёму. разве шёл разговор про то, какой инструмент тут подойдёт лучше? я тебе про пример реализации. а ты так и не ответил.
Я всё ответил. Для оптимизации есть SQL, его и бери. Если нативная трансляция устраивает, за ней приоритет. Всё просто, не нужно ничего выдумывать.

hVosttМСУВопросы хранения данных и архитектура хранилища никак не должны зависить от способов материализации чего-то там.
вот именно! поэтому всё выше сказанное -- типичное противоречие самому себе. с базой данных работает только менеджеры баз данных. работать надо не с базой, а данными. у тебя получается наоборот.
В чем именно противоречие? И что такое "менеджеры баз данных"? С базой данных работают приложения, а никакие не менеджеры. Структура базы не должна зависеть ни от каких ORM и прочего. У базы могут быть 100500 клиентов, даже на разных языках.

hVosttМСУБездумно писать ef-запросы ведет к деградации личности и непонимании принципов работы с БД.
вот это я вообще не понял. что значит бездумно писать ef-запросы? принципы работы с БД -- вот что развращает. реляционная природа у данных только в СУБД. для прикладного приложения есть объекты. ты работаешь с базой данных, а я с бизнес-моделью.
Это значит, что нужно понимать 100% во что транслируется ef-запрос. Если этого понимания нет, ORM противопоказана. ORM для тех, кто понимает, что такое SQL.

hVosttты думаешь, что в EF не добавили групповой Remove/Update потому что им тяжело было? или некогда? или не до этого им? почему? все эти наезды типо в NH это уже давно есть, а МС так и не удосужится прикрутить... этих механизмов там быть попросту не должно быть. изначально они там нафиг не сдались. а почему, похоже, пока до некоторых не доходит
EF уже очень долго пилится, в начальных версиях это было вообще УГ. И все мы юзали L2S или хибер. Пока ты под столом пешком ходил. Может когда-то и добавят в EF фичу, но суть не об этом.

hVosttМСУТак это не работа EF с CTE, а работа EF с вьюхой. Это разные вещи. А реально бы хотелось трансляцию CTE, как это умеет делать NH. Да и объектов в БД будет меньше, это плюс.
CTE это понятие, уместное только при реляционном подходе.
Ты чё несешь, какой реляционный подход? CTE - это рекурсия

hVosttчто конкретно требуется от CTE, это получить уровень и "путешествие" вверх/вниз по дереву. обычная вьюха прекрасно справляется с этой задачей. просто великолепно. а EF работает с объектами. ничего другого он не понимает и не должен понимать. вьюха там или таблица, или табличная функция -- по барабану. это кортеж данных. всё
Ты понимаешь разницу между вьюхой и табличной функцией или хп? Только подумай, не торопись с ответом.

hVosttNH просто делала разношёрстная толпа, которая по максимуму напихала туда всё, чтобы удовлетворить всех и каждого. EF же реализует SOLID-ный подход к решению очень чётко определённой задачи. а начинающие ребята (или олд скул) хотят продолжать ковыряться в базе с помощью SQL-я. в таком случае EF -- не больше чем банальный маппер. но это не так. это целая абстракция. и любая дыра, даже маленькая в 10% выльется в лужу проблем. кто хочет и способен удержать всё под постоянным строгим контролем, та ради бога.
Мля, какой SOLID... Пипец, ты инопланетянен Серьезно, хватит пороть чушь в тех вещах, в которых не разбираешься. Иначе опять будет стыдно, как в случае LINQ Expression. Не неси ересь. EF это не маппер, это ORM. Маппера у меня в рецептах валяются, поделки на 3 строки кода.