Код-перший-модель / база даних-перший [закрито]

Які плюси та мінуси використання Entity Framework 4.1 Код спочатку над Модель / База даних спочатку з діаграмою EDMX?

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

Я знаю, що можу використовувати підхід, кодовий перший: визначати мої сутності та контекст вручну та використовувати ModelBuilderдля тонкої настройки схеми.

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

В обох випадках я закінчую POCOоб'єктом, який є ORMагностиком і контекстом, який випливає DbContext.

Перша база даних здається найбільш привабливою, оскільки я можу спроектувати базу даних у Enterprise Manager, швидко синхронізувати модель та точно налаштувати її за допомогою конструктора.

То яка різниця між цими двома підходами? Це лише про перевагу VS2010 проти Enterprise Manager?

Я думаю, що різниці:

Код спочатку

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

Перша база даних

• Дуже популярний, якщо у вас є БД, розроблена DBA, розроблена окремо, або якщо у вас є існуючі БД.
• Ви дозволите EF створити сутності для вас, і після модифікації карти ви генеруватимете сутності POCO.
• Якщо ви хочете отримати додаткові функції в об'єктах POCO, ви повинні або змінити шаблон T4 або використовувати часткові класи.
• Вручну зміни бази даних можливі, оскільки база даних визначає вашу модель домену. Ви завжди можете оновити модель з бази даних (ця функція працює досить добре).
• Я часто використовую це спільно з проектами VS Database (лише версія Premium та Ultimate).

Модель спочатку

• IMHO популярний, якщо ви любитель дизайнера (= вам не подобається писати код або SQL).
• Ви "намалюєте" свою модель і дозволите робочому процесу генерувати сценарій вашої бази даних, а шаблон T4 генерувати ваші сутності POCO. Ви втратите частину контролю над своїми організаціями та базою даних, але для невеликих легких проектів ви будете дуже продуктивними.
• Якщо ви хочете отримати додаткові функції в об'єктах POCO, ви повинні або змінити шаблон T4 або використовувати часткові класи.
• Зміни в базі даних вручну, швидше за все, будуть втрачені, оскільки ваша модель визначає базу даних. Це краще, якщо у вас встановлений блок живлення для генерації баз даних. Це дозволить вам оновити схему баз даних (замість відтворення) або оновити проекти баз даних у VS.

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

Я думаю, що це просте "дерево рішень" Джулі Лерман, автор програми "Рамка програмування", повинно допомогти прийняти рішення з більшою впевненістю:

Детальніше тут .

Перша база даних та модель спочатку не мають реальних відмінностей. Створений код однаковий, і ви можете комбінувати цей підхід. Наприклад, ви можете створити базу даних за допомогою дизайнера, ніж ви можете змінити базу даних за допомогою sql-скрипту та оновити свою модель.

Під час використання коду ви не можете змінити модель без бази даних для відпочинку та втрати всіх даних. ІМХО, це обмеження дуже суворе і не дозволяє спочатку використовувати код у виробництві. Наразі це не справді корисно.

Другий незначний недолік коду - це те, що розробник моделі вимагає привілеїв на головній базі даних. Це не вплине на вас, якщо ви використовуєте базу даних 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. З цього моменту ви будете додавати міграції, розмічені з позначками часу та марковані дескриптором, щоб допомогти впорядкувати версії. Коли ви зателефонуєте на додавання міграції з менеджера пакунків, буде створений новий файл міграції, що містить все, що змінилось у вашій кодовій моделі автоматично, як у функціях UP (), так і DOWN (). Функція UP застосовує зміни до бази даних, функція DOWN видаляє ті самі зміни у випадку, коли ви хочете відкатати. Більше того, ви можете редагувати ці файли міграції, щоб додати додаткові зміни, такі як нові представлення даних, покажчики, збережені процедури та все інше. Вони стануть справжньою системою версій для вашої схеми бази даних.

Код-першим представляється висхідною зіркою. Я швидко ознайомився з Ruby on Rails, і їх стандарт є першим за кодом, з міграцією бази даних.

Якщо ви створюєте програму MVC3, я вважаю, що Код спочатку має такі переваги:

• Легке декорування атрибутів - Ви можете прикрашати поля з валідацією, вимагати тощо. Атрибути, це досить незручно з моделюванням EF
• Ніяких дивних помилок моделювання - EF моделювання часто має дивні помилки, наприклад, коли ви намагаєтесь перейменувати властивість асоціації, воно має відповідати основним метаданим - дуже негнучким.
• Не незручно для злиття - при використанні інструментів контролю версій коду, таких як меркурій, об'єднання файлів .edmx - це біль. Ви програміст, звик до C #, і там ви об’єднуєте .edmx. Не так з кодом.
• По-перше, поверніться до Кодексу, і ви маєте повний контроль без усіх прихованих складностей і невідомих питань, з якими можна боротися.
• Я рекомендую використовувати інструмент командного рядка Package Manager, навіть не використовувати графічні інструменти для додавання нового контролера для перегляду ешафотів.
• Міграція DB - тоді ви також можете включити міграцію. Це так потужно. Ви вносите зміни в свою модель в код, і тоді фреймворк може відслідковувати зміни схеми, тому ви можете безперешкодно розгортати оновлення, при цьому версії схеми автоматично оновлюються (і при необхідності понижуються). (Не впевнений, але це, ймовірно, працює і з моделлю спочатку)

Оновлення

Питання також вимагає порівняння коду-першого з моделлю EDMX / db-first. Код-спочатку також може бути використаний для обох цих підходів:

• Перша модель : спочатку кодування POCO (концептуальна модель), а потім генерування бази даних (міграції); АБО
• База даних по-перше : з огляду на існуючу базу даних, вручну кодуйте POCO, щоб вони відповідали. (Різниця тут полягає в тому, що POCO не генеруються автоматично, надають існуючу базу даних). Ви можете наблизитись до автоматичного, однак використовуючи Створення POCO-класів та відображення існуючої бази даних за допомогою Entity Framework або Entity Framework 5 - Як генерувати класи POCO з існуючої бази даних .

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

Код EF спочатку і модель спочатку здалися крутими і забезпечують незалежність бази даних, однак, роблячи це, це не дозволяє вказати те, що я вважаю дуже базовою та загальною інформацією про конфігурацію бази даних. Наприклад, індекси таблиці, метадані безпеки або мають первинний ключ, що містить більше одного стовпця. Я вважаю, що хочу використовувати ці та інші загальні функції бази даних, і тому в будь-якому разі доводиться безпосередньо робити конфігурацію бази даних.

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

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

Робота з великими моделями була дуже повільною до SP1, (не пробували її після SP1, але, як кажуть, зараз це просто).

Я все-таки спочатку проектую свої таблиці, потім вбудований інструмент генерує для мене POCO, тому він бере на себе тягар виконання повторюваних завдань для кожного об'єкта poco.

коли ви використовуєте системи управління джерелами, ви можете легко стежити за історією своїх POCO, це не так просто з кодом, створеним дизайнером.

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

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

І нарешті, я не люблю дизайнерів.

Приклад першого підходу до бази даних:

Без написання коду: Перший підхід / База даних даних ASP.NET MVC / MVC3

І я вважаю, що це краще, ніж інші підходи, оскільки втрата даних при такому підході менша.

IMHO Я думаю, що у всіх моделей є чудове місце, але проблема, з якою я маю перший підхід до моделі, полягає у багатьох великих підприємствах, де DBA контролює бази даних, ви не отримуєте гнучкості у створенні програм без використання перших підходів до бази даних. Я працював над багатьма проектами, і коли справа доходила до розгортання, вони хотіли повного контролю.

Отже, наскільки я згоден з усіма можливими варіаціями Code First, Model First, Database first, ви повинні врахувати фактичне виробниче середовище. Тож якщо у вашій системі буде велика програма для користувачів із багатьма користувачами та DBA веде шоу, то ви можете розглянути перший варіант бази даних лише на мою думку.

Я думаю, що першим з переваг коду є те, що ви можете створити резервну копію всіх змін, які ви внесли до системи контролю версій на зразок Git. Оскільки всі ваші таблиці та зв’язки зберігаються в тому, що по суті є просто класами, ви можете повернутися назад у часі і подивитися, якою була структура вашої бази даних раніше.