archeliteNHibernate?

archelite,

http://metanit.com/sharp/entityframework/

archelite,

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

СмузиhVosttгенерации БД из классов со всеми связями ...миграции
Бесполезная функция для корпоратива. Никто не даст учеткам апп / пула для обновлении схемы данных. Только полноценный VS Database Project со всей его фундаментальностью и мощью. Миграции - детская шелуха для дева и теста.

Это речь старпёра, который держится за свой SQL из последних своих сил. Говорю по существу, уже много проектов, и крупных, секьюрных и ответственных, было выпущено на миграциях. В начале тоже было много сомнений, отдельные упоротые SQL-щики из последних сил бодались и яростно защищали свой любимый дизайн БД, боясь странного и неизведанного.

Тут главное не засцать, и всё будет путём :) Миграции -- величайший вин.

Насчёт каких-то там учёток с правами, знаешь, я разницы не вижу, грохнешь ли ты таблицу, или покоцаешь данные — однофигственно. Поэтому это всё детские страхи. От бекапов никуда не денешься, все миграции проверяются на ряде стендов, пока доходят до релиза. CI понимаешь.

Зато в базу ручонками никто не лезет. Всё под полным контролем.

СмузиhVostt, сразу видно, что дальше десятка таблиц в БД ты не ходил :)

Ты кажется не понимаешь о чём говоришь. Количество таблиц? Ты смешон. Текущая разработка над которой мы работаем генерирует тысячи таблиц, любой ДБА там встанет раком и возопит «помилуйте».


СмузиНикто не даст права учетной записи app / pool на изменение схемы данных. Есть четкое разделение ответственности, причем тут "упоротые SQL-щики"? Дев выкатывает change requests, прикладывает документ с обновления с нужными скриптами в пакете.

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

Ты мне скажи, в чём принципиальная разница между изменением схемы и данных? Я вижу разницу только в том, кто это делает. Приложение делает это по заданным оттестированным, проверенным и надёжным алгоритмам.


СмузиНикто не пишет никакой SQL. В MS Database Project достаточно инструментов для ведения схемы, данных, генерации схемы, генерации тестовых данных, merge в обе стороны, sync, много всего. Миграции это детский сад по сравнению с MS Database Project :)

Под SQL я имею в виду ручную манипуляцию схемой и данными. Как именно ты это будешь делать, писать SQL, или возить мышкой в дизайнере -- не имеет значения. При чём, никто не мешает писать тебе тот же SQL в миграции. Фишка в том, что количество затраченного времени сокращается колоссально, это проверено опытном путём за последние годы разработки. Никто больше не возится с проектами БД, тем более, что баз данных гораздо больше, чем одна.

СмузиЧем твоя генерация тысячи таблиц отличается от генерации тысячи таблиц в MS Database Project?

Тем что она напрямую связана с кодом. Коду нужна таблица, она будет создана. Коду нужно поле в таблице, оно будет создано. Коду нужна связь. Она будет создана. Не нужно привлекать дополнительные силы, чтобы проверять требуемое соответствие. Не нужно сначала создавать таблицу, потом писать код. Не нужно писать код, потом лезть в дизайнер и сверяясь с названиями создавать нужную структуру. Всё это автоматизировано.

СмузиЕсть уровни ответственности. Обновление данных / схемы на продуктиве - это не ответственность разработчика как по вопросам безопасности, так и по вопросам той самой ответственности. Пойди предложи накатить EF-миграцию в каком-нибудь Альфа банке, тебя кастрируют еще на подходе к данному уровню

Я ещё раз повторю. Чем отличается возможность изменять данные и возможность изменять схему с точки зрения безопасности? Говоря об Альфа-Банке, пользователя волнует состояние и безопасность счёта, данные и схема здесь в абсолютно равной позиции.

По поводу накатывания миграци. Чем это отличается от накатыванием изменений в БД другим инструментом? Если ты делаешь это вручную, то яйца твои останутся в целости? Не смеши.


Смузи1. Никакой разницы с точки зрения ответственности (регламент по сопровождению приложений, в частности change request).
2. Огромная разница с точки зрения ответственности (работающее приложение).

Поясни конкретно в чём разница по пункту 2? Если приложение само контролирует схему, которая нужна ему для работы и гарантирует, что она будет содержать всё нужное, то здесь только плюсы. Минусы какие?


СмузиP.S. Хвост, это мой последний пост по теме. Ибо чистый оффтоп. Если ты понял суть, молодец. Если нет, продолжай решать свои школьные миграции, я не против.

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

archelite,

Разве в БД этих связей нет? Связи в EF организуются навигационными свойствами. Связь на другую таблицу, это свойство на объект класса, представляющего эту таблицу:





ObjectOne ссылается на ObjectTwo, а в ObjectTwo есть коллекция всех объектов ObjectOne, которые на него ссылаются (определять эту коллекцию не обязательно, но даёт большую гибкость при написании запросов).

При этом подразумевается, что в БД в таблице ObjectOne будет присутствовать foreign key с именем ObjectTwo_Id.

В общем, в доках всё очень подробно написано.