Актуальность Entity Framework 6

Подскажите, пожалуйста, востребован ли сейчас Entity Farmework 6 или есть более удобные средства для работы с БД?

0

MsGuns, ну, справедливости ради могу сказать, что большая часть описанного - закономерное следствие использования генерации моделей и мастера этой самой генерации. Мы от такого подхода отказались и не пожалели. Модельки пишем руками (code first), так существенно удобнее.

Сообщение от MsGuns При работе с паттерном "DataBase First" (а у меня именно такая ситуация т.к. на момент разработки проектов БД уже имеется, и не маленькая) приходится писать для шаблонов расширения классов модели в отдельных юнитах, отчего код становится более громоздким и менее читабельным. Кроме того, при малейших изменениях этот код приходится править ручками.

А вот это уже звучит как не совсем корректное обращение с модельками EF'а. Вы какую-то бизнес-логику добавляете таким образом к сущностям?

И про хранимые процедуры я не понял. У вас сущности проецируются на хранимки?

1

Usaga,

Ну да. Шаблоны валидации например: ScaffoldColumn, Required и т.д.

Хранимки.
Имеются в виду SP на сервере, которые должны вернуть некий НД, мапированный в Модель как класс QbjectResult, в коде которых несколько Select`ов. EF как правило, неверно трактует ЕДИНСТВЕННЫЙ возвращаемый НД. И, как правило, не тот, который требуется.
Можно, конечно, возвращать из SP несколько НД, но внятного и прозрачного механизма для работы с ними в EF нет. "Распознается" только первый, для доступа к остальным приходится писать код и ручками приводить к нужному типу.
Поэтому пишу такие SP, чтобы они возвращали один НД и так, чтобы EF распознавал и мапировал в модель именно его.

В общем, на реальных задачах кроме классов и контекста Модели EF приходится городить еще дополнительные классы-модели и репозиторий (репозитории). Т.е. получается "пирог" из ORM: снизу - EF, сверху - собственный. И это еще при том, что я - фулстэк и "хозяйничаю" в БД на SQL-сервере. Если бы был ограничен доступ к БД (а я знаю что это такое - работал с Oracle в "Парус" с "птичьими" правами), было бы совсем грустно

Добавлено через 15 минут
Тут ведь какое дело.
Есть множество способов "абстрагирования", которые предоставляет шарп. Имеется в виду имплиментация.
Это, может быть, хорошо, но это и бесит ! Особенно поначалу. Когда четко знаешь ЧТО надо сделать, но сомневаешься КАК.
Нативный сиквел (xxxClient), функциональный (from..), linq, IF, куча всего другого (не пробовал, но видел).
После php например, все это кажется "кучей-малой" и к тому же по-разному работает с разными типами серверов (провайдерами).
Я, к примеру, не совсем понимаю логику разрабов EF. Ну зачем пихать результаты SP и UDF в разные типы ? Только потому, что SP ВСЕГДА возвращает int, а UDF - нет ? Или потому, что SP возвращает несколько результатов, которые могут быть как скалярами, так и НД, и при этом еще out-paramtter ?
Ну так напишите ОДИН класс, имеющий несколько разных интерфейсов, но чтобы все они были совместимы.
Выходные параметры ? Для UDF - они null. Несколько НД ? Бога ради - для UDF только один (если есть). Код возврата ? Пожалуйста: для SP - это return, для скалярной UDF - возвращаемое значение, для UDF с НД - кол-во записей например.
И так далее..

Добавлено через 13 минут

Сообщение от Usaga сущности проецируются на хранимки

Наоборот вообще-то
Хранимки (юзер-функции) - на сущности (классы).
Это очень удобно. Есть множество случаев сложной реализации алгоритмов выборок и расчетов в БД.
Зачем эти алгоритмы писать на клиенте (а ORM - это чистейшей воды "клиент" относительно SQL-сервера), тем более, что он могут меняться абсолютно автономно от тех или иных пользовательских приложений.
Можно , например, какой - нибудь хитрый и ветвящийся отчет завернуть в SP, причем заюзать там вторичные индексы, залезть в другие БД и много еще чего. Причем будет полная гарантия еще и того, что на сервере все это будет бегать куда быстрее. То же самое касается и сложных модификаций, когда изменения должны быть сделаны во многих таблицах. Тут еще и возникает проблема транзакционности, которая, кстати, вернее механизм управления транзакциями, практически никак не решена в EF. То, что там есть, даже "транзакцией" назвать нельзя, не говоря уж о полноте управления ею.

Поэтому я по возможности логику пишу на сервере. А в ORM вкладываю то, что уже является "продуктом" работы сервера.
Вот и получается, что в большинстве проектов у меня в конструкторе EF либо пустота, либо несколько простых сущностей типа справочников болтаются. Все остальное (десятки) - это результаты UDF и SP, отмапированные IF в классы и контент (методы).

Ругать меня за такой подход можно. Но, наверное, не нужно ибо бесполезно

Добавлено через 8 минут

Сообщение от MsGuns Но, наверное, не нужно ибо бесполезно

Мне думается, что в наши дни начинающему инженеру лучше учиться работать с абстракциями (моделями). Есть мощные средства, инженера не "тяготит" уже полученный опыт и квалификация, зато нет даже базовых понятий SQL-аппарата (язык + возможности и ограничения SQL-сервера). Он как бы получает "воплощение" своей идеи автоматически. И это, возможно, хорошо. Не знаю. Так не работал. Попробовал - не понравилось

С СУБД работаю давно, с конца 80-х. Когда еще все эти ORM только рождались в мозгах умных людей. Поэтому копаться в "кишках" БД для меня не проблема - скорее удовольствие

1

Сообщение от MsGuns Хранимки. Имеются в виду SP на сервере, которые должны вернуть некий НД, мапированный в Модель как класс QbjectResult, в коде которых несколько Select`ов. EF как правило, неверно трактует ЕДИНСТВЕННЫЙ возвращаемый НД. И, как правило, не тот, который требуется. Можно, конечно, возвращать из SP несколько НД, но внятного и прозрачного механизма для работы с ними в EF нет. "Распознается" только первый, для доступа к остальным приходится писать код и ручками приводить к нужному типу. Поэтому пишу такие SP, чтобы они возвращали один НД и так, чтобы EF распознавал и мапировал в модель именно его.

Я не до конца понял описанную тут проблему, но у меня сложилось очень устойчивое ощущение, что EF для вашей задачи просто не подходит. Такое бывает.

Сообщение от MsGuns Хранимки (юзер-функции) - на сущности (классы). Это очень удобно. Есть множество случаев сложной реализации алгоритмов выборок и расчетов в БД. Зачем эти алгоритмы писать на клиенте (а ORM - это чистейшей воды "клиент" относительно SQL-сервера), тем более, что он могут меняться абсолютно автономно от тех или иных пользовательских приложений.

Это второй и более громкий звонок в пользу бесполезности EF для вашего проекта. Силам таких ORM как EF, Linq2Db и NHibernate в том, что они позволяют вам почти не обращаться к SQL и реализовывать свои запросы в коде. Если вы всё равно пишете хранимки (для отчётов ладно, там действительно хранимки разумнее применять), то EF для вас практически бесполезен. Можно Dapper.NET взять и не париться.

Сообщение от MsGuns Тут еще и возникает проблема транзакционности, которая, кстати, вернее механизм управления транзакциями, практически никак не решена в EF. То, что там есть, даже "транзакцией" назвать нельзя, не говоря уж о полноте управления ею.

Что вы имеете в виду? Чекпоинты нельзя создавать? Или что?

Сообщение от MsGuns Мне думается, что в наши дни начинающему инженеру лучше учиться работать с абстракциями (моделями). Есть мощные средства, инженера не "тяготит" уже полученный опыт и квалификация, зато нет даже базовых понятий SQL-аппарата (язык + возможности и ограничения SQL-сервера). Он как бы получает "воплощение" своей идеи автоматически. И это, возможно, хорошо. Не знаю. Так не работал. Попробовал - не понравилось

Бизнес-модели никак не противоречат наличию сущностей по которым ORM может строить запросы. Просто нельзя эти вещи смешивать ни в коем случае в одном классе. И такой подход действительно распространнён: прочитали из базы проекцию (набор проекций, если нам нужен аггрегат), завернули её в бизнес-модель, которая ни про какие базы ничего не знает и отправили её наверх, в бизнес-логику.

2

Usaga,

Весьма интересно и познавательно. Серьезно.

Но вот ситуация. Есть Предметная Область (ПО). Есть ряд задач, которые поставлены и решены. Уже. Есть БД, в которой помимо информации, имеется еще и весьма значительная бизнес-логика. Тоже уже. И без меня.
Моя задача - реализовать новую задачу в этой ПО. Доступ на сервер есть. Но - без коррекции имеющейся бизнес-логики.
Т.е. можно писать новые SP/View/UDF.., даже создавать новые таблицы, но старые трогать нельзя понятно почему.

Что бы Вы посоветовали в данной ситуации кроме EF ?

1

Сообщение от MsGuns Что бы Вы посоветовали в данной ситуации кроме EF ?

Тут нужно обсудить с тимлидом\архитектором\коллегами стратегию дальнейшей работы с архитектурой приложения. Бизнес-логику удобнее писать на чём-то одном. На C# писать очевидно удобнее, чем на SQL.

Я бы рассмотрел вариант отказа от использования хранимых процедур для нового функционала и перехода на EF \ Linq2Db. Тогда большую часть логики можно будет писать на C# сильно в SQL не суясь. И поддерживать миграции базы станет чуть проще, ибо не придётся перенакатывать\удалять хранимые процедуры, запросы-то на ходу генерируются. Но будет и минус: смесь подходов (SP в старом коде, EF \ Linq2Db в новом), что безусловно будет мозолить глаза немного. Ну и придётся вникать в возможности ORM. Некоторые запросы с тем же EF может быть весьма не просто написать. Я, даже спустя годы, могу до нескольких часов потратить на написание запроса на EF или на его оптимизацию. Правда такое уже всё реже)

Если же решите остаться на старом подходе с хранимками, то EF (и Linq2Db) вам ни в какие ворота. Всю их мощь вы заменяете хранимками и UDF. Тогда достаточно взять простую Micro-ORM: Dapper.NET или PetaPOCO. Они вам просто будут мапить выборки на модельки и модельки на параметры хранимок. Ровно то, что вам и надо.

Вы не считайте EF каким-то Must Have для вообще любой работы с СУБД. Если вы запросы берёте на себя (по любой уважительной или не очень причине), то EF становится не полезнее простого Dapper'а.

1

Сообщение от Usaga Если вы запросы берёте на себя (по любой уважительной или не очень причине), то EF становится не полезнее простого Dapper'а.

Короче, даппер Будем посмотреть

Добавлено через 15 минут
Посмотрел Dapper на метаните.

Как я понял, он дает по сути единственный полезный метод Query<Model class>.
Сами модели при этом создаются "ручками" (Code First)

Пока я не понял особой разницы между даппером и "нативным SQL" XXXClient. Там и там запросы в коде, там и там репозиторий и опять же ручной код.

При использовании EF SQL в коде нет совсем. Т.е. абсолютно. Во всяком случае в моих проектах. linq используется, конечно, но на "локальном уровне" - сортировки, простенькие группировки и т.д. Как правило, на стороне "клиента", когда сортируется уже извлеченный с SQL-сервера набор.

Управление транзакциями также "ручное", т.е. составление SQL-скриптов. Такой метод я применял лет 10 назад.
Более нет ни малейшего желания.

Вопрос: есть ли смысл копать и пробовать дальше, а также понюхать Linq2Db, PetaPOCO и так далее ?
В чем их принципиальное отличие от даппера и EF ?

1

Сообщение от Usaga На C# писать очевидно удобнее, чем на SQL

Вот это ключевая фраза.
Для кого "очевидно" ?
Для меня - отнюдь

1

Сообщение от MsGuns Пока я не понял особой разницы между даппером и "нативным SQL" XXXClient.

Она в том, что вы не достаёте руками данные из *Reader, оно вам на классы и коллекции классов само всё мапит. И точно так же, параметры руками не пихаете. А текст запроса полностью на вас. Т.е. вы не теряете в гибкости возможных запросов. В вашем случае весь SQL, который вам нужен - exec имя процедуры @param1 @param2...

EF тут вам бесполезен. Вы всё равно процедуры пишете. Ну а то, что якобы у вас SQL'я нет с EF'ом не правда. У вас всё равно есть конфигурация каждой сущности привязывающая её к хранимке. Т.е. количество кода тоже самое. Разница в использовании даппера будет в том, что у вас не будет никаких EDMX, не будет ни какого разогрева контекста, будут только репозитории с методами содержащими единственные вызовы *Query<T>("exec spname", params) и всё.

И про транзакции я не понял, что вам не нравить.

1

Сообщение от Usaga Кто один на EF? Каждый экземпляр контекста EF открывает своё собственное подключение к базе для каждого запроса. Внезапно. Тоже самое делает и Linq2Db. И обеих ORM этот момент настраиваемый. EF запросы ни в какие очереди не ставит. И ещё раз: причём тут необходимость вычитывать из базы удаляемые позже записи? Это один фиг два разных запроса. Без внешней транзакции это не несёт ровным счётом никакой пользы.

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

Сообщение от Usaga Нужно, чтобы он свою основную работу нормально выполнял, а не был огрызком умеющим во все технологии, но по чуть-чуть. Мне никак не помогает это "подружить", если каждую вторую фичу SQL'а не поддерживает. Что мне толку, что EF умеет дружить с тем, что мне не нужно?

EF опенсорсный, если он не умеет с тем что вам нужно, то студию в зубы и вперед, непаханное поле пулреквестов вас ждет.

Сообщение от Usaga Кто куда упирается? Причём тут Linq2Sql? Для EF 6 и Core модели никаким образом не генерируются? Для WinForms и WPF тоже код форм не генерируется и всё упирается в Linq2SQL? Этому подходу, с генерацией, уже двадцать лет. Просто решили пойти дальше. А вы говорите, что это тупик.

Что? Я говорил о производительности сопоставимой с linq2sql. Это древняя технология, но быстрая. Без проблем уделывающая любые новоделы типа linq2db.

Сообщение от Usaga И причём тут EF, асинхронщина и прочее? Обычный конкурентный доступ на уровне СУБД. Тут даже C# не причём, не то, что EF. Вы можете более конкретный пример привести, где будет видно, как чтение данных перед их удаление поддерживает согласованность данных?

Лол. Вы таки серьезно? Вы вобще в курсе как асинхронные вызовы работают? Пара await'ов в методе могут раскидать выполнение по куче потоков. И да, EF гарантирует согласованность данных, остальные ORM нет. Что до примера, это не простая вещь, как и все в параллельном программровании. Ну нельзя просто так показать частный случай параллельного выполнения кода - он не будет гарантированно повторяться, в этом его главная сложность.

Сообщение от Usaga Вот это, конечно, меня просто убило. Одно подключение на весь EF) А транзакции конкурентные как с таким должны работать?)) Транзакция тоже одна на весь EF? У одного клиента ошибка, все параллельные тут же тоже откатываются, да?)

Сообщение от Usaga я так понимаю, что он исходил из ошибочного представления о том, что у EF одно подключение на все контексты и что EF какие-то очереди формирует из запросов. Только у меня это всё равно никак не накладывается на "происходит столкновение с рассинхроном контекста

Не несите бред. Transeit один на запрос, количество потоков нелимитировано.

1

Сообщение от freeba Речь о том что контекст он один, даже для нескольких запросов из паралельных потоков, в пределах одного процесса.

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

Сообщение от freeba EF опенсорсный, если он не умеет с тем что вам нужно, то студию в зубы и вперед, непаханное поле пулреквестов вас ждет.

Зачем, если есть Linq2Db, где почти всё, что мне нужно уже реализовано? Мир не крутится вокруг EF ни разу.

Сообщение от freeba Что? Я говорил о производительности сопоставимой с linq2sql. Это древняя технология, но быстрая. Без проблем уделывающая любые новоделы типа linq2db.

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

Сообщение от freeba Лол. Вы таки серьезно? Вы вобще в курсе как асинхронные вызовы работают? Пара await'ов в методе могут раскидать выполнение по куче потоков. И да, EF гарантирует согласованность данных, остальные ORM нет. Что до примера, это не простая вещь, как и все в параллельном программровании. Ну нельзя просто так показать частный случай параллельного выполнения кода - он не будет гарантированно повторяться, в этом его главная сложность.

Во-первых, то что код после await переедет в другой поток (что можно и запретить) ничего не меняет - контекст в этом потоке всё равно один, запросы через этот контекст всё равно только из одного потока формируются. Поэтому о каких рассинхронах тут идёт речь я всё ещё не понимаю. Во-вторых, вы так и не довели до меня, как EF реализует согласованность и как другой ORM эту согласованность можно нарушить.

Сообщение от freeba Не несите бред. Transeit один на запрос, количество потоков нелимитировано.

Что за Transeit?

В общем, давайте посмотрим на пример кода, где увидим (хоть и под отладкой):
* Что контекст один на весь процесс
* Как происходит рассинхронизация контекста, что бы это ни было
* Увидим как EF реализует согласованность и тот же запрос без EF, где эта согласованность нарушается.

От этого и будем плясать. А так, вы мне какую-то дичь втираете и рисуете EF совершенно неюзабельным средством работы с СУБД. Мне, как человеку уже пять лет с EF работающим очень плотно, очень смешно читать эти заявления про волшебные рассинхроны, единичные контексты и прочие согласованности данных реализуемым бог знает как.

0

Сообщение от Usaga Вообще-то, на каждый запрос - свой экземпляр контекста

Кхмм.. Это Вы серьезно ? Т.е. если я в одном методе контроллера хочу прочитать данные (один запрос), потом изменить их (второй запрос) и опять перечитать весь набор включая измененную запись (третий запрос), то для этого нехитрого действа мне нужно 3 (ТРИ) экземпляра контекста ?

Или я чегой-то недопонял ?

Сообщение от Usaga где почти всё, что мне нужно уже реализовано

Очень серьезный аргумент. Т.е. если мне нравится ходить в туфлях на босу ногу, то все как бы тоже должны ?

Сообщение от Usaga Мне, как человеку уже пять лет с EF работающим очень плотно, очень смешно читать эти заявления про волшебные рассинхроны, единичные контексты и прочие согласованности данных реализуемым бог знает как.

Никто тут не сомневается в Вашей квалификации, но..
Я где-то тут Вам пытался рассказать про транзакции, в смысле невозможность нормального управления ими в EF (это про "рассогласованность" если чо), но Вы не стали заострять тему.

Про "единичные" контексты просто не понял - см. выше.

Добавлено через 12 минут
И еще про

Сообщение от MsGuns согласованности данных реализуемым бог знает как.

Вам, как человеку с опытом работы с БД, безусловно, знакомо словосочетание "Целостность данных".
Так вот, в нормальных, подчеркиваю,- нормальных БД, эта самая целостность заложена в бизнес-логику сервера.
Ну, всякие там форейнкеи, каскады и прочие "кишки". И никакими танцами с бубном с костром с черепами в виде Dupper, IHibernate, Linq2sql, EF и пр. эту целостность Вам порушить не удастся.
Проще говоря, если у Вас есть в дочерней таблице ссылка на какую-то запись в главной, то удалить эту самую запись Вам не удастся никакими молитвами ! Если опять-таки на том же самом сервере на этот ключ не повешено каскадное удаление.

Хотя, конечно, можно создать "базу" с линейными, независимыми друг от друга, как свинья на льду, таблицами. Тогда, уж конечно, заботиться о "согласованности" данных в этих таблицах приходится в самих приложениях - логика "обрастает" кодом, как собака репейниками.

"Зато мы делаем ракеты", т.е. не "лезем на сервер", ага ?

0

Сообщение от MsGuns Кхмм.. Это Вы серьезно ? Т.е. если я в одном методе контроллера хочу прочитать данные (один запрос), потом изменить их (второй запрос) и опять перечитать весь набор включая измененную запись (третий запрос), то для этого нехитрого действа мне нужно 3 (ТРИ) экземпляра контекста ? Или я чегой-то недопонял ?

Я не точно выразился. Да, сбил с толку. Я имел в виду веб-приложение. Один HTTP-запрос от пользователя. freeba DI всякие упоминает, асинхронщину и потоки. Конечно же, имелось в виду некое многопользовательское приложение.

Сообщение от MsGuns Очень серьезный аргумент. Т.е. если мне нравится ходить в туфлях на босу ногу, то все как бы тоже должны ?

Это не имеет ничего общего с тезисом, который вы комментируете. Причём тут все и нравится\не нравится? Есть две ORM: "урезанный" по функционалу EF и более продвинутый Linq2Db. Оба бесплатны. И мне утверждают, что если мне чего-то не хватает в EF, то надо брать и допиливать это. Я вот и спрашиваю: зачем, когда рядом лежит допиленная ORM за те же деньги? Более того, что значить "допиливать"? У авторов EF'а есть чёткое видение своей ORM как имитатора объектной модели, где нет места тем вещам, которых мне не хватает. Там хоть додопиливайся, PR'ы всё равно не примут. Да я и всё равно в упор понять не могу, зачем нужно доделывать что-то в одном инструменте, когда можно просто взять доделанный?

Сообщение от MsGuns Никто тут не сомневается в Вашей квалификации, но.. Я где-то тут Вам пытался рассказать про транзакции, в смысле невозможность нормального управления ими в EF (это про "рассогласованность" если чо), но Вы не стали заострять тему.

Я вас прямо спросил про этот момент:

Сообщение от Usaga И про транзакции я не понял, что вам не нравить.

Сообщение №28. Я так и не получил ответ. Видимо вопрос просто потерялся на фоне количества текста.

Сообщение от MsGuns Вам, как человеку с опытом работы с БД, безусловно, знакомо словосочетание "Целостность данных". Так вот, в нормальных, подчеркиваю,- нормальных БД, эта самая целостность заложена в бизнес-логику сервера. Ну, всякие там форейнкеи, каскады и прочие "кишки". И никакими танцами с бубном с костром с черепами в виде Dupper, IHibernate, Linq2sql, EF и пр. эту целостность Вам порушить не удастся. Проще говоря, если у Вас есть в дочерней таблице ссылка на какую-то запись в главной, то удалить эту самую запись Вам не удастся никакими молитвами ! Если опять-таки на том же самом сервере на этот ключ не повешено каскадное удаление. Хотя, конечно, можно создать "базу" с линейными, независимыми друг от друга, как свинья на льду, таблицами. Тогда, уж конечно, заботиться о "согласованности" данных в этих таблицах приходится в самих приложениях - логика "обрастает" кодом, как собака репейниками. "Зато мы делаем ракеты", т.е. не "лезем на сервер", ага ?

Вы мне это зачем рассказываете? Я это всё прекрасно понимаю. Я не вас спрашивал, а freeba, когда он заговорил о том, что EF-де согласованность обеспечивает. Причём о согласованности он заговорил как о аргументе к моему вопросу о том, почему в EF нет возможности производить пакетные обновления изменения записей. И даже удаление делается через задницу в виде или выгрузки сущности или создании экземпляра класса сущности с выставление ID и аттачем к контексту. На что я получил ответ: EF так согласованность данных обеспечивает. Вот я и захотел продолжения услышать о том, что за согласованность обеспечивается таким образом.

А мне вы не рассказывайте про внешние ключи. Я про них не хуже вашего знаю.

0

Сообщение от Usaga Сообщение №28. Я так и не получил ответ. Видимо вопрос просто потерялся на фоне количества текста.

"Расшифрую".

Вот есть такое понятие как "цепочка проводок" в бухгалтерии. Это когда есть некий документ, который обрабатывается (проводится) через изменения в куче "таблиц", причем могут удаляться/изменяться/добавляться кучи записей в этих таблицах. В EF, как известно, нельзя через модели делать множественные изменения (вернее можно, но крайне неудобно) и в одной таблице и тем более нескольких связанных.

Самый простой пример:
Вот есть приходная накладная. Помимо заголовка (дата, номер, поставщик, сумма и т.д.), этот документ в базе представлен еще как минимум, фактурой и несколькими записями об оплате. Кроме того он отражается на складе - а это все в других таблицах. Надо этот документ удалить. Что мне нужно в EF ? Где имеется 4 класса модели: "Документ", "Состав документа (фактура)", "Банковские выписки", "Склад".
Как прикажете писать удаление документа ? В цикле перебирать "детали" в каждой из трех таблицах и каждой давать Remove ? А потом оптом SaveChanges для всей базы ? Ну чтобы было удалено все и везде либо ничего и нигде ?
Здесь ситуация, когда целостность невозможно соблюсти "штатными" средствами сервера. Нужна бизнес-логика.

И есть механизм - Stored Proc. Но лазить ручками на сервер мы не можем - Коран не позволяет - все через Модель и только хардкор, пардон, Code First.

Я по сравнению с Вами, новичок в EF, много чего не знаю. Но с БД работаю, смею предположить, поболее Вас. Вот расскажите мне, как всю эту лабуду залепить в одну транзакцию, которую можно будет либо подтвердить либо удалить. С помощью механизма EF исключительно ? Буду весьма признателен ибо у меня не получилось, хотя пытался

0

Сообщение от MsGuns Как прикажете писать удаление документа ? В цикле перебирать "детали" в каждой из трех таблицах и каждой давать Remove ? А потом оптом SaveChanges для всей базы ? Ну чтобы было удалено все и везде либо ничего и нигде ? И есть механизм - Stored Proc. Но лазить ручками на сервер мы не можем - Коран не позволяет - все через Модель и только хардкор, пардон, Code First.

Обычно так всегда и делают. Не видел другого. Именно так - все таблицы перебираются для удаления нужных записей. И потом савеЧанжес.
Насчёт удаления. Для сохраннности данных разве не принято просто ставить флаг "IsDeleted", а не удалять физически? Мало того что следов не найти потом. Дак и странно что "коран 1С" это позволит. Столько связей может потеряться.

Ну и чем SP отличается от действия цикла? В SP вы что-то другое делаете? не перебираете таблицы?

0

Ремарочка к приведенному примеру со складом.
Банковские выписки и склад удалять, конечно, не нужно, их нужно апдейтить

Добавлено через 3 минуты

Сообщение от HF Насчёт удаления. Для сохранности данных разве не принято просто ставить флаг "IsDeleted"

Да, это так в реальности. Но я немного упростил для наглядности.

Сообщение от HF Ну и чем SP отличается от действия цикла? В SP вы что-то другое делаете? не перебираете таблицы?

Не понял. Чего я "перебираю" в SP ? Есть язык SQL, а в нем предикат Where.

0

Сообщение от MsGuns Вот есть такое понятие как "цепочка проводок" в бухгалтерии.

В бухгалтерии нет такого понятия, это есть у 1С (отсюда видимо и хотелка про структуру подчиненности), так что....Если вам не нравится ваш сосед, то вы просто не умеете его готовить

0

.. я честно скажу, когда меня в определенной части документооборота стали напрягать эти "множественные связи" в плане создания/удаления/редактирования тупой накладной, я решил отказаться от связанных таблиц, и хранить вложенные объекты документа (списки ТМЦ и т.д.) в виде JSON прямо в плоской таблице ... Тем более, что сейчас и в SQL-запросах можно использовать FromJSON, а уж сериализаторов полно во всех вариантах и серверной, и клиентской части ...
ЗЫ: ни коим образом не предлагаю к использованию, просто размышления ...

0

Кроме того в SQL-серверах есть еще триггеры.
Вот, кстати, еще зверюшки, оперирование которыми в модели (любой, включая EF) - для меня как бином Ньютона.
Также,кстати, как и планы запросов, вторичные индексы, курсоры, временные таблицы и прочие плюшки, которые так иногда полезны, даже незаменимы при разработке серверной бизнес-логики. Как с ними в EF или том же расхваливаемым linq2sql ?

0

Сообщение от MsGuns Я по сравнению с Вами, новичок в EF, много чего не знаю. Но с БД работаю, смею предположить, поболее Вас. Вот расскажите мне, как всю эту лабуду залепить в одну транзакцию, которую можно будет либо подтвердить либо удалить. С помощью механизма EF исключительно ? Буду весьма признателен ибо у меня не получилось, хотя пытался

Я не совсем понял где тут вырисовываются неудобные транзакции.

Решение номер один: внешние ключи на "Документ" с ON CASCADE DELETE. Удаляем "Документ", удаляются все с ним связанные данные силами самой СУБД (EF не причём).

Решение номер два: выгружаем весь граф объектов подлежащих удалению (тут уже preformance penalty) и говорим EF'у удалить "Документ". Все связанные данные EF снесёт отдельными командами DELETE. EF умеет догадаться о типе и направлении отношений, но можно и конфигурацией это поднастроить.

Решение номер три: если нет ключей и нет возможности полагаться на EF, то ходить руками вызывать Remove.

Все три действия от вас ничего не потребуют в плане работы с транзакциями, ибо SaveChanges() выполнит все эти действия в одной транзакции.

Если этого мало, то можно воспользоваться классом TransactionScope() для оборачивания серии обращений к базе в одну единую транзакцию.

Я пока не вижу, что вы лично увидели неудобного. Может я не так вас понял?

0

Сообщение от MsGuns Кроме того в SQL-серверах есть еще триггеры. Вот, кстати, еще зверюшки, оперирование которыми в модели (любой, включая EF) - для меня как бином Ньютона. Также,кстати, как и планы запросов, вторичные индексы, курсоры, временные таблицы и прочие плюшки, которые так иногда полезны, даже незаменимы при разработке серверной бизнес-логики. Как с ними в EF или том же расхваливаемым linq2sql ?

Триггеры, вторичные индексы и планы запросов к EF и Linq2Db отношения не имеют. Это аспекты СУБД. С временными таблицами Linq2Db работать умеет (EF нет). С курсорами, насколько я знаю, ни одна ORM не работает. Это уж извините)

Добавлено через 52 секунды
Ах да, в Linq2Db есть ещё зачаточная поддержка Query Hints. Вроде планируют расширить поддержку этого дела. Тоже приятный бонус.

0