Первый код - сначала модель/база данных

Ответ 1

Я думаю, что различия:

Код первый

• Очень популярен, потому что хардкорным программистам не нравятся какие-либо дизайнеры, и определение отображения в EDMX xml слишком сложно.
• Полный контроль над кодом (нет автоматически сгенерированного кода, который трудно изменить).
• Общее ожидание заключается в том, что вы не беспокоитесь о БД. БД - это просто хранилище без логики. EF будет заниматься созданием, и вы не хотите знать, как оно работает.
• Ручные изменения в базе данных, скорее всего, будут потеряны, потому что ваш код определяет базу данных.

База данных первая

• Очень популярен, если у вас есть БД, разработанная администратором баз данных, разработанная отдельно, или если у вас есть БД.
• Вы позволите EF создавать объекты для вас, и после модификации отображения вы будете создавать объекты POCO.
• Если вам нужны дополнительные функции в объектах POCO, вы должны либо изменить шаблон T4, либо использовать частичные классы.
• Ручные изменения в базе данных возможны, потому что база данных определяет модель вашего домена. Вы всегда можете обновить модель из базы данных (эта функция работает довольно хорошо).
• Я часто использую это вместе с проектами VS Database (только Premium и Ultimate версия).

Модель первая

• ИМХО популярно, если вы фанат дизайнеров (= вам не нравится писать код или SQL).
• Вы "нарисуете" свою модель, и пусть рабочий процесс сгенерирует ваш скрипт базы данных, а шаблон T4 сгенерирует ваши объекты POCO. Вы потеряете часть контроля над своими сущностями и базой данных, но для небольших простых проектов вы будете очень продуктивными.
• Если вам нужны дополнительные функции в объектах POCO, вы должны либо изменить шаблон T4, либо использовать частичные классы.
• Ручные изменения в базе данных, скорее всего, будут потеряны, потому что ваша модель определяет базу данных. Это работает лучше, если у вас установлен блок питания для создания базы данных. Это позволит вам обновить схему базы данных (вместо воссоздания) или обновить проекты базы данных в VS.

Я ожидаю, что в случае EF 4.1 есть несколько других функций, связанных с Code First и Model/Database сначала. Свободный API, используемый в Code сначала, не предлагает все функции EDMX. Я ожидаю, что такие функции, как сопоставление хранимых процедур, представления запросов, определение представлений и т.д. DbContext первом использовании Model/Database и DbContext (я еще не пробовал), но в первую очередь их нет в Code.

Ответ 2

Я думаю, что это простое "дерево решений" Джули Лерман, автор книги "Programming Entity Framework", должно помочь принять решение с большей уверенностью:

Подробнее Здесь.

Ответ 3

Сначала база данных и модель не имеют реальных различий. Сгенерированный код тот же, и вы можете комбинировать эти подходы. Например, вы можете создавать базу данных с помощью конструктора, чем изменять базу данных с помощью sql script и обновлять свою модель.

При первом использовании кода вы не можете изменить модель без базы данных отдыха и потерять все данные. ИМХО, это ограничение очень строгое и не позволяет использовать код сначала в производстве. Пока что это действительно не применимо.

Второй второстепенный недостаток кода заключается в том, что разработчик модели требует привилегий в основной базе данных. Это не влияет на вас, если вы используете базу данных SQL Server Compact или управляете сервером базы данных.

Преимущество кода в первую очередь - очень чистый и простой код. Вы полностью контролируете этот код и можете легко модифицировать его и использовать в качестве своей модели просмотра.

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

Ответ 4

Цитирование соответствующих частей из http://www.itworld.com/development/405005/3-reasons-use-code-first-design-entity-framework

3 причины использовать дизайн кода сначала с Entity Framework

1) Меньше беспорядка, меньше вздутия

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

С первым кодом ваши модели с ручным кодом становятся вашей базой данных. Точные файлы, которые вы создаете, - это то, что создает дизайн базы данных. Нет никаких дополнительных файлов, и нет необходимости создавать расширение класса, когда вы хотите добавить свойства или что-то еще, о чем база данных не должна знать. Вы можете просто добавить их в тот же класс, если вы соблюдаете правильный синтаксис. Черт возьми, вы даже можете сгенерировать файл Model.edmx для визуализации вашего кода, если хотите.

2) Большой контроль

Когда вы сначала обращаетесь к БД, вы зависите от того, что генерируется для ваших моделей для использования в вашем приложении. Иногда соглашение об именах нежелательно. Иногда отношения и ассоциации не совсем то, что вы хотите. В других случаях непостоянные отношения с ленивой загрузкой наносят ущерб вашим ответам API.

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

3) Контроль версий базы данных

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

При первом включении миграций генерируется класс конфигурации и начальная миграция. Начальная миграция - это ваша текущая схема или базовая версия v1.0. С этого момента вы добавите миграции, которые имеют временную метку и помечены дескриптором, чтобы упорядочить версии. Когда вы вызываете add -igration из диспетчера пакетов, будет сгенерирован новый файл миграции, содержащий все, что автоматически изменилось в вашей модели кода в функциях UP() и DOWN(). Функция UP применяет изменения к базе данных, функция DOWN удаляет те же самые изменения в случае, если вы хотите выполнить откат. Более того, вы можете редактировать эти файлы миграции, чтобы добавлять дополнительные изменения, такие как новые представления, индексы, хранимые процедуры и все остальное. Они станут настоящей версионной системой для вашей схемы базы данных.

Ответ 5

Code-first кажется восходящей звездой. Я быстро взглянул на Ruby on Rails, и их стандарт - сначала код, с миграциями баз данных.

Если вы создаете приложение MVC3, я считаю, что сначала у Code есть следующие преимущества:

• Простое оформление атрибутов - Вы можете украшать поля с помощью атрибутов проверки, требования и т.д., Это довольно неудобно с EF-моделированием
• Никаких странных ошибок моделирования - в моделировании EF часто возникают странные ошибки, например, когда вы пытаетесь переименовать свойство ассоциации, оно должно соответствовать базовым метаданным - очень негибким.
• Не неудобно объединять - при использовании инструментов контроля версий кода, таких как mercurial, объединение файлов .edmx является проблемой. Вы программист, привыкший к С#, и там вы объединяете .edmx. Не так с первым кодом.
• Сравните сначала с кодом, и вы получите полный контроль без каких-либо скрытых сложностей и неизвестных ситуаций.
• Я рекомендую вам использовать инструмент командной строки Package Manager, даже не используйте графические инструменты для добавления нового контроллера в представления скаффолдов.
• DB-Migrations - тогда вы также можете включить-Migrations. Это так сильно. Вы вносите изменения в свою модель в коде, а затем инфраструктура может отслеживать изменения схемы, чтобы вы могли беспрепятственно развертывать обновления с автоматически обновляемыми версиями схемы (и, при необходимости, пониженными). (Не уверен, но это, вероятно, работает и с моделью в первую очередь)

Обновить

Этот вопрос также требует сравнения кода-первого с моделью EDMX/db-first. Code-first можно использовать для обоих этих подходов:

• Модель сначала: сначала кодируем POCO (концептуальная модель), затем генерируем базу данных (миграции); ИЛИ ЖЕ
• Первая база данных: учитывая существующую базу данных, вручную кодируйте соответствующие POCO. (Разница здесь в том, что POCO не генерируются автоматически, что дает существующую базу данных). Однако вы можете приблизиться к автоматическому, используя Generate POCO классы и сопоставление для существующей базы данных, используя Entity Framework или Entity Framework 5. Как генерировать POCO классы из существующей базы данных.

Ответ 6

Сначала я использую базу данных EF, чтобы обеспечить большую гибкость и контроль над конфигурацией базы данных.

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

Я считаю, что классы POCO по умолчанию, созданные во время БД, очень чисты, однако не имеют очень полезных атрибутов аннотации данных или сопоставлений хранимых процедур. Я использовал шаблоны T4 для преодоления некоторых из этих ограничений. Шаблоны T4 являются удивительными, особенно в сочетании с вашими собственными метаданными и частичными классами.

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

Ответ 7

Работа с крупными моделями была очень медленной до SP1 (не пробовал это после SP1, но сказано, что теперь это привязка).

Я все же сначала создаю свои таблицы, а встроенный встроенный инструмент генерирует для меня POCOs, поэтому для каждого объекта poco требуется бремя выполнения повторяющихся задач.

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

У меня есть база для моего POCO, что делает многое довольно просто.

У меня есть представления для всех моих таблиц, в каждом базовом представлении содержится основная информация о моих внешних ключах, и мои представления POCOs выводятся из моих классов POCO, что очень полезно снова.

И, наконец, мне не нравятся дизайнеры.

Ответ 8

Пример первого подхода к базе данных:

Без написания какого-либо кода: ASP.NET MVC/MVC3 База данных Первый подход/База данных в первую очередь

И я думаю, что это лучше, чем другие подходы, потому что при таком подходе потеря данных меньше.

Ответ 9

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

Так что, насколько я согласен со всеми возможными вариантами Code First, First First, Database, вы должны рассмотреть фактическую производственную среду. Поэтому, если ваша система станет крупным пользовательским базовым приложением со многими пользователями и администратором базы данных, работающим в шоу, тогда вы можете рассмотреть вариант базы данных только по моему мнению.

Ответ 10

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