Код сначала против модели / базы данных сначала [закрыт]

Каковы плюсы и минусы использования Entity Framework 4.1 сначала кода, а не модели / базы данных сначала с диаграммой EDMX?

Я пытаюсь полностью понять все подходы к созданию уровня доступа к данным с использованием EF 4.1. Я использую репозиторий и шаблон IoC.

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

Я также могу создать EDMXдиаграмму и выбрать шаг генерации кода, который использует шаблоны T4 для генерации тех же POCOклассов.

В обоих случаях я получаю POCOобъект, который не зависит от ORMконтекста и контекста DbContext.

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

Так в чем же разница между этими двумя подходами? Это просто предпочтение VS2010 по сравнению с Enterprise Manager?

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

Код первый

• Очень популярен, потому что хардкорным программистам не нравятся какие-либо дизайнеры, и определение отображения в 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. Я ожидаю, что такие функции, как отображение хранимых процедур, представления запросов, определение представлений и т. Д., Работают при первом использовании Model / Database и DbContext(я еще не пробовал), но в первую очередь их нет в Code.

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

Больше информации здесь .

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

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

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

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

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

Цитирование соответствующих частей из 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 удаляет те же самые изменения в случае, если вы хотите выполнить откат. Более того, вы можете редактировать эти файлы миграции, чтобы добавлять дополнительные изменения, такие как новые представления, индексы, хранимые процедуры и все остальное. Они станут настоящей версионной системой для вашей схемы базы данных.

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

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

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

Обновить

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

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

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

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

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

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

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

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

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

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

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

И, наконец, я не люблю дизайнеров.

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

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

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

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

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

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