EF code first — бажная технология, в которой описание структуры бд размазывается как по коду с помощью атрибутов([Key], [ForiegnKey], ...),
так и в Fluent api.
От версии к версии EF Code first ломается в разных местах, в тоже время не реально правильно описать структуру бд, что бы вдруг EF code first случайно не создало лишних ключей/индексов; после написания каждой строчки в C# надо все-равно приходится смотреть какой sql скрипт создает EF code first на выходе.
А если в бд используются функции/процедуры, то тут все становится еще печальнее, приходится перемешивать C# код с sql.
С помощью Code First даже миграции накатываются ооочень медлено.
Поддерживать перемешанный C#/sql код становится в разы сложнее чем отдельно sql и C#.
Есть ли вообще будущее у EF Code First?
Підтримати Україну у боротьбі з країною-терористом.
Здравствуйте, #John, Вы писали:
J>Здравствуйте,
J>EF code first — бажная технология, в которой описание структуры бд размазывается как по коду с помощью атрибутов([Key], [ForiegnKey], ...), J>так и в Fluent api. J>От версии к версии EF Code first ломается в разных местах, в тоже время не реально правильно описать структуру бд, что бы вдруг EF code first случайно не создало лишних ключей/индексов; после написания каждой строчки в C# надо все-равно приходится смотреть какой sql скрипт создает EF code first на выходе. J>А если в бд используются функции/процедуры, то тут все становится еще печальнее, приходится перемешивать C# код с sql. J>С помощью Code First даже миграции накатываются ооочень медлено. J>Поддерживать перемешанный C#/sql код становится в разы сложнее чем отдельно sql и C#.
J>Есть ли вообще будущее у EF Code First?
А вариантов? Народ же по-прежнему мечтает менять СУБД по первому чиху.
Здравствуйте, #John, Вы писали:
J>Есть ли вообще будущее у EF Code First?
Любой однобокий подход ущербен по сути — идёшь ты от данных или от кода. Истина всегда посередине: обе стороны могут изменяться и только вдумчивое ручное управление синхронизацией позволяет получать адекватный результат.
В моей практике какая бы ни была простая база, всегда находится заковыка, не позволяющая тупо описать POCO и надеяться, что "само всё синхронизируется".
Здравствуйте, #John, Вы писали:
J>Здравствуйте,
J>EF code first — бажная технология, в которой описание структуры бд размазывается как по коду с помощью атрибутов([Key], [ForiegnKey], ...), J>так и в Fluent api.
Так не размазывайте, он же это позволяет и так и так.
J>От версии к версии EF Code first ломается в разных местах, в тоже время не реально правильно описать структуру бд, что бы вдруг EF code first случайно не создало лишних ключей/индексов; после написания каждой строчки в C# надо все-равно приходится смотреть какой sql скрипт создает EF code first на выходе. J>А если в бд используются функции/процедуры, то тут все становится еще печальнее, приходится перемешивать C# код с sql. J>С помощью Code First даже миграции накатываются ооочень медлено. J>Поддерживать перемешанный C#/sql код становится в разы сложнее чем отдельно sql и C#.
J>Есть ли вообще будущее у EF Code First?
Вот без малейшего понятия. Я Code First отвергаю как явление. Но ежи лезли на кактус долго.
Базу данных надо проектировать, а не ляпать энтити по хотелке. FluentMigrator или ручные миграции вам в помощь и scaffold.
Да и сторед процы для базы генерят не от богатства выбора, а когда натыкаются на очередное ограничение сего богатого на фичи фреймворка, но еще далекого от настоящей разрабоки высоконагруженных систем.
Здравствуйте, #John, Вы писали:
J>EF code first — бажная технология, в которой описание структуры бд размазывается как по коду с помощью атрибутов([Key], [ForiegnKey], ...),
Не размазывайте. Соберите все описания в одном месте.
J>Есть ли вообще будущее у EF Code First?
В чистом виде, когда БД именно создается по коду — не уверен. Может для каких простых проектов и подойдет.
Мне же нравится "гибридный" подход — когда БД создается отдельно, а CF описания используется для маппинга кода на БД. IMHO результат получается удобнее и легче для поддержки, чем генерить сущности по БД.
Здравствуйте, Doc, Вы писали:
Doc>В чистом виде, когда БД именно создается по коду — не уверен. Может для каких простых проектов и подойдет.
Doc>Мне же нравится "гибридный" подход — когда БД создается отдельно, а CF описания используется для маппинга кода на БД. IMHO результат получается удобнее и легче для поддержки, чем генерить сущности по БД.
А искать несоответствия типов и прочие ошибки потом как? IMHO удобнее всего генерить классы реверся бд.
Здравствуйте, BlackEric, Вы писали:
BE>А искать несоответствия типов и прочие ошибки потом как?
Ну такое вылезет еще на этапе дебага (особенно если грубые). Честно говоря я не помню когда мы на такое наталкивались в последний раз. Но сейчас у нас уже и БД "устоявшаяся".
BE>IMHO удобнее всего генерить классы реверся бд.
Ну самое простое — что если нейминг в БД не совпадает с неймингом в DAL (считаю что БД создается разработчиками БД, а DAL и логику уже пишут разработчики на C#).
Здравствуйте, #John, Вы писали:
J>Здравствуйте,
J>EF code first — бажная технология, в которой описание структуры бд размазывается как по коду с помощью атрибутов([Key], [ForiegnKey], ...), J>так и в Fluent api. J>От версии к версии EF Code first ломается в разных местах, в тоже время не реально правильно описать структуру бд, что бы вдруг EF code first случайно не создало лишних ключей/индексов; после написания каждой строчки в C# надо все-равно приходится смотреть какой sql скрипт создает EF code first на выходе. J>А если в бд используются функции/процедуры, то тут все становится еще печальнее, приходится перемешивать C# код с sql. J>С помощью Code First даже миграции накатываются ооочень медлено. J>Поддерживать перемешанный C#/sql код становится в разы сложнее чем отдельно sql и C#.
J>Есть ли вообще будущее у EF Code First?
Мне это напоминает измышления "язык высокого уровня vs ассемблер". Когда-то тоже казалось, что асм форева, а всё остальное для поделок на коленке. Однако поди ж ты — уже выросло поколение, не знающее почему 'xor Ax,Ax' лучше чем 'move Ax,0'
BE>А искать несоответствия типов и прочие ошибки потом как? IMHO удобнее всего генерить классы реверся бд.
Этот генератор загаживает код так, что потом только им и пользоваться, а руками туда лезть становится страшно.
Когда у вас станет ооочень много объектов базы, он начнет дико тормозить. Плюс отображение всех этих объектов — это каша без возможности группировки.
И, если вопрос лишь в том, чтобы увеличить размер поля или сменить тип, то приходится долго искать этот объект, а добавление новой таблицы — долго ждать загрузки всего списка из базы без возможности фильтрации.
Создание маппинга, конечно, тупая и скучная работа. Зато потом править легко и приятно.
Здравствуйте, Danchik, Вы писали:
D>Так не размазывайте, он же это позволяет и так и так.
Через атрибуты много сделать нельзя, напр. добавлять составные ключи на несколько полей.
Атрибуты сильно различаются между версиями EF в некоторых версиях один, в других другие, в EF core вообще половины из EF их нет.
D>Вот без малейшего понятия. Я Code First отвергаю как явление.
Да, лучше сначала делать БД с миграциями в SQL скриптах, а в EF просто делать маппинг на таблицы.
Підтримати Україну у боротьбі з країною-терористом.
Здравствуйте, #John, Вы писали:
J>Через атрибуты много сделать нельзя, напр. добавлять составные ключи на несколько полей.
Так для этого есть fluent настройки. Используем только их и ничего не размазывается. Отлично подходит для случая когда бд создаётся отдельно, а в коде средствами CF создаётся маппинг
Здравствуйте, Mr.Delphist, Вы писали:
MD>Мне это напоминает измышления "язык высокого уровня vs ассемблер". Когда-то тоже казалось, что асм форева, а всё остальное для поделок на коленке. Однако поди ж ты — уже выросло поколение, не знающее почему 'xor Ax,Ax' лучше чем 'move Ax,0'
Ишь ты! Во-первых xor ax, ax только ситуационно лучше, чем mov ax, 0, т.к. портит регистр флагов, а посему имеет меньший потенциал применимости (параллельное исполнение, зависимые команды). Конечно, на Z80 это был лучший выбор всегда, когда нас не интересовал регистр флагов.
Но, все таки сравнивать это мне кажется не совсем корректно, и даже бессмысленно: EF CF придумали люди которые никогда в жизни не видели объемных БД (по числу объектов), модульных (в разных деплоях — разный набор объектов, а приложения лишь знают о своих объектах), и просто не понимают, что апгрейд (с изменением структуры) — это процесс, который требует культуры и подготовки, а именно, бэкап до, апгрейд, деплой, боевая проверка. Апгрейд с весьма ненулевой долей вероятности может обломиться, по причине того, что разработчики не учли всего, и конверсия данных сдулась на ровном месте, или уборщица обесточила серверную. А может и просто кривую версию выпустили всего — необходимо откатить, т.к. за оставшееся время на обслуживание ясно, что систему не запустить. Как потом восстановить тот хотя бы гигабайт данных, который испорчен? При этом эта процедура могла затрагивать много объектов, и ни в какую одну транзакцию оно не влазит, никакой "транзакционности" невозможно, если не хочется что-бы апгрейд занял двое суток, на что бизнес, естественно не пойдет. Это сугубо административный процесс. Я тут безусловно местами утрирую, но тем не менее, мы как-то делали мажорный апгрейд где чистое время работы сиквела на конвертацию — около 8 часов. Это очень большое время, это же не за пару секунд напедалить и попробовать.
Потом появился SSDT который дал даже готовые тулзы из коробки которые хорошо работают. Хотя мы и без него неплохо обходились, местами со своими довольно простыми тулзами.
В итоге, мне лично проще делать "database-first", с нормальными генераторами классов, навроде linq2db, а не в стиле EF.) Либо, если данные БД можно легко воссоздать (для тестов например) — то её проще переподнять полностью, и закачать туда данные.
Опять же, т.к. БД работает не на водороде, то ее проектирование — это важный этап. И мне глубоко пофигу, если в EF/клиенте неудобно получить желаемую пропертю, т.к. структура выбирается исходя из соображения необходимого баланса между потребностями запросов и занимаемого пространства, с уклоном в скорость запросов, и тут далеко не всегда работает нормальная форма (без фанатизма, но некоторые данные выгоднее "перегруппировать" так, что бы меньше было строк, хотя бы за счет роста таблицы в ширину.)
Т.н. code first позволяет пропустить кучу шагов, не зацикливаться, и тому подобное, но в финале, я наблюдал это только так, что люди писали там марсианские классы, которые потом приходилось переделывать полностью, более, чем в три раза: структуру БД, в результате получается 10-100х уменьшение хранимого мусора, и даже уже в следствии этого — ощутимое ускорение, само по себе ощутимое ускорение потому как... сделано не идеально, но с любовью, и весь связанный клиентский код, который вместо безбожной дури творит, то, что его просили, давая суммарный выигрыш в абсолютных числах около часа (задача начинает выполняться внезапно 5 секунд, а лопатит несколько млн строк). Ну и естественно, эта работа не бесплатно достается работодателю.
Есть еще историй много, где вместо дурацкого кластера со всеми модными наворошками всего-то надо было правильно поднять и настроить ровно один сервер. Но это из области "не интересно". Зачем делать правильно БД, если вместо этого можно поднять кластер мутни по которой даже статистику без приседаний не соберешь, а клиенткая библиотека в асинхронном вызове использует блокирующую очередь, чего на трэд пуле делать не очень хорошо, вплоть до дедлока сервера, когда в ответ на голодание, рантайм откажется спаунить новые потоки.
Мои байки — конечно, достаточно экстремальны по своему характеру, но нажиты личным опытом.
В общем, очень плохо, что новое поколение не знает разницы между xor ax, ax и mov ax, 0 и/или каких-то базовых фундаментальных вещей.
PS: Хотя, я конечно согласен, что для определенного класса задач EF CF применим, но это всё же это нишевой и замкнутый подход. А преподносят красивыми словами-то какими... И C/C++/C# vs asm тут не идет ни в какое сравнение, потому, что CF — это такой своеобразный brainfuck. Вроде как и язык, да не то...
Здравствуйте, #John, Вы писали:
J>Да, лучше сначала делать БД с миграциями в SQL скриптах, а в EF просто делать маппинг на таблицы.
В EF лучше вообще ничего не делать. Он создавался людьми которые видели БД только в теории и для таких же теоретиков.
Я когда задумываюсь — "как я докатился до такой жизни?" через некоторое время вспоминаю, что все началось с (реляционной) базы данных у которой очень "забавная" структура.
Под неё (структуру) потом всё и писалось.
-- Пользователи не приняли программу. Всех пришлось уничтожить. --
Здравствуйте, Doc, Вы писали:
BE>>А искать несоответствия типов и прочие ошибки потом как? Doc>Ну такое вылезет еще на этапе дебага (особенно если грубые). Честно говоря я не помню когда мы на такое наталкивались в последний раз.
Честно говоря тогда вообще непонятно зачем вам ORM. Писали бы всё на хранимках, а ошибки как-то сами вылезут на этапе дебага например.
Здравствуйте, Max Mustermann, Вы писали:
MM>Честно говоря тогда вообще непонятно зачем вам ORM. Писали бы всё на хранимках, а ошибки как-то сами вылезут на этапе дебага например.
Все на хранимках? А, я понял! Вам просто делать на работе нечего, раз у вас есть такие мысли.
Здравствуйте, Коваленко Дмитрий, Вы писали: КД>Я когда задумываюсь — "как я докатился до такой жизни?" через некоторое время вспоминаю, что все началось с (реляционной) базы данных у которой очень "забавная" структура.
Ох-хо-хо. И мы такое ж писали. Только там была не чистая реляционка, а самопальная ORM. Но она не была code-first. Там был лютый трэш и угар.
Впрочем, нас извиняет то, что всякие Фаулеры написали свои фундаментальные труды примерно на 5-10 лет позже. А так — да, UI был ровно такой же именно.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Мы уже победили, просто это еще не так заметно...
