3 причины использовать дизайн кода сначала с Entity Framework
1) Меньше беспорядка, меньше вздутия
Использование существующей базы данных для генерирования файла модели .edmx и связанных моделей кода приводит к огромной куче автоматически сгенерированного кода. Вы умоляете никогда не трогать эти сгенерированные файлы, чтобы не сломать что-либо, иначе ваши изменения не будут перезаписаны в следующем поколении. Контекст и инициализатор также смешаны в этом беспорядке. Когда вам нужно добавить функциональность к вашим сгенерированным моделям, например, вычисляемое свойство только для чтения, вам нужно расширить класс модели. Это становится требованием почти для каждой модели, и вы получаете расширение для всего.
С первым кодом ваши модели с ручным кодом становятся вашей базой данных. Точные файлы, которые вы создаете, - это то, что генерирует дизайн базы данных. Нет никаких дополнительных файлов, и нет необходимости создавать расширение класса, когда вы хотите добавить свойства или что-то еще, о чем база данных не должна знать. Вы можете просто добавить их в тот же класс, если вы соблюдаете правильный синтаксис. Черт возьми, вы даже можете сгенерировать файл Model.edmx для визуализации вашего кода, если хотите.
2) Большой контроль
Когда вы сначала обращаетесь к БД, вы зависите от того, что генерируется для ваших моделей для использования в вашем приложении. Иногда соглашение об именах нежелательно. Иногда отношения и ассоциации не совсем то, что вы хотите. В других случаях непостоянные отношения с ленивой загрузкой наносят ущерб вашим ответам API.
Несмотря на то, что решение проблем генерации моделей почти всегда можно решить, код сначала дает вам полный и точный контроль с самого начала. Вы можете управлять всеми аспектами как своих моделей кода, так и дизайна базы данных, не выходя из своего бизнес-объекта. Вы можете точно указать отношения, ограничения и ассоциации. Вы можете одновременно устанавливать ограничения символов и размеры столбцов базы данных. Вы можете указать, какие связанные коллекции должны загружаться или не быть сериализованными вообще. Короче говоря, вы несете ответственность за другие вещи, но вы полностью контролируете дизайн своего приложения.
3) Контроль версий базы данных
Это большой. Управление версиями баз данных сложно, но с первым кодом и миграцией кода вначале это намного эффективнее. Поскольку ваша схема базы данных полностью основана на ваших моделях кода, с помощью управления версиями вашего исходного кода вы помогаете версии вашей базы данных. Вы несете ответственность за контроль инициализации своего контекста, который может помочь вам сделать такие вещи, как начальные фиксированные бизнес-данные. Вы также несете ответственность за создание кода первой миграции.
При первом включении миграций генерируется класс конфигурации и начальная миграция. Начальная миграция - это ваша текущая схема или базовая версия v1.0. С этого момента вы добавите миграции, которые имеют временную метку и помечены дескриптором, чтобы упорядочить версии. Когда вы вызываете add -igration из диспетчера пакетов, будет сгенерирован новый файл миграции, содержащий все, что автоматически изменилось в вашей модели кода в функциях UP () и DOWN (). Функция UP применяет изменения к базе данных, функция DOWN удаляет те же самые изменения в случае, если вы хотите выполнить откат. Более того, вы можете редактировать эти файлы миграции, чтобы добавлять дополнительные изменения, такие как новые представления, индексы, хранимые процедуры и все остальное. Они станут настоящей версионной системой для вашей схемы базы данных.