Чи призначений CodeFirst для широкомасштабних додатків?

Я читав про Entity Framework, зокрема, EF 4.1 та переходив за цим посиланням ( http://weblogs.asp.net/scottgu/archive/2010/07/16/code-first-development-with-entity- Framework-4.aspx ) та його посібник з Code First.

Я вважаю це акуратним, але мені було цікаво, чи перший Code повинен бути просто рішенням для швидкого розвитку, де можна просто заскочити прямо, не плануючи чи це насправді призначене для використання у великих масштабах?

Можливо, у мене там є деякі недоброзичливці, але коли я прочитав деякі з цих постів від Hanselman та Gutherie, а потім прочитав книгу Джулії Лерман про Entity Framework, то в мене був справді важкий час з кодом. За багато років побудови додатків я пройшов багато шляхів, як вимушених процесом, так і вибором, і виявив, що маю набагато більший успіх у створенні даних, орієнтованих на дані при створенні програми.

Я говорю про лінійку бізнес-додатків тут ... це коли у вас є бізнес-проблеми або процес, який повинен мати за собою програмне рішення. У вас є дані, якими потрібно якось керувати. Краще знати свої дані та те, як вони стосуються себе та як вони використовуються в бізнесі. Тому ви моделюєте ці дані, а потім створюєте навколо себе додаток / рішення. На моєму досвіді, якщо ви починаєте створювати додаток із даними, як заздалегідь, щось врешті-решт залишається осторонь, і тоді у вас є деякий рефакторинг (у багатьох випадках - ОСНОВНИЙ рефакторинг).

Невеликі програми можуть бути винятком, але я продовжую використовувати підхід, орієнтований на дані.

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

З мого досвіду, наскільки ефективно КФ у великому проекті сильно залежить від того, наскільки абстрагується ваш рівень даних від бізнес-рівня.

Наприклад, в одному з моїх проектів бізнес-рівень безпосередньо викликає базу даних через linq. Я використовую Linq для вилучення шару бази даних і використовую CodeFirst для відображення моїх POCO в схемі бази даних. У цьому випадку CodeFirst значно спрощує підтримку відмінностей між умовами DB (відносини та назви таблиць) та моїми іменами класу C # набагато простіше, і я можу зробити зміни в базі даних, не впливаючи на взаємодію мого бізнес-рівня з базою даних.

Однак в іншому проекті я абстрагував доступ до бази даних у негенерованому шаблоні репозиторію, і методи Get * мого сховища несуть повну відповідальність за виконання запитів у базі даних, і вони повертають реальні об'єкти (не IQueryable<T>s). У цьому випадку методи репозиторію перетворюють об'єкти БД в об'єкти POCO, і в цьому випадку CodeFirst не приносить вам такої великої користі, оскільки POCOs CodeFirst недовговічні і швидко перетворюються у класи C # бізнес-рівня.

Зрештою, це дійсно залежить від того, наскільки структурована команда та наскільки комфортно команді (або людям похилого віку) з інженерами, які не входять у DBA, що змінюють схеми бази даних, і наскільки зміни схем вплинуть на структуру коду. Коли CodeFirst відображено в існуючій базі даних, для мене тривіально перекомпонувати властивість до нового імені стовпця без необхідності робити глобальне перейменування цього імені властивості, що особливо є фактором, коли ви говорите про ім’я, яке має більше сенсу для поля бази даних, а не властивості C #. Для мене також тривіально додавати підтримку коду для нових полів бази даних, не потребуючи повністю переробляти мої сутності C # (одна з причин я залишив Linq-to-sql в EF CodeFirst з існуючої бази даних).

Код Перший не підходить для широкомасштабних додатків. Поворот розвитку масштабних додатків дуже величезний.

Зазвичай життєвий цикл вашої бізнес-програми такий,

1. Версія 1 знаходиться у виробництві
2. Версія 2 знаходиться в бета-версії
3. Версія 3 знаходиться в активному розвитку
4. Версія 4 планується.

Є й інші комунікаційні мости між додатками, деякі заплановані завдання, третя сторона інтеграція, веб-сервіси для деяких різних комунікаційних пристроїв, таких як мобільний тощо.

В кінцевому підсумку Код спочатку використовує ObjectContext Entity Model, Старіший EF, що генерує EDMX та використовує ObjectContext з EntityObject, справді достатньо для всього. Ви можете легко налаштувати текстовий шаблон для генерування коду. Метод виявлення змін відбувається повільніше з реалізацією ObjectContext, але замість генерування проксі, команда EF могла б легко покращити швидкість виявлення змін замість того, щоб спочатку винаходити код.

Автоматизована міграція

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

Код першої міграції зовсім не підходить в такій системі. Версія 1 та версія 2, швидше за все, спілкуються з однією базою даних. Версії 3 та Версії 4 зазвичай є поетапними та мають різні бази даних.

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

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

Текстові шаблони

Ми створили власні текстові шаблони для запиту та створення EDMX та ObjectContext з невеликою спеціальною реалізацією, яка стосується проблем продуктивності. Існує кілька додатків з різними версіями, які спілкуються з однією базою даних без проблем.

Для мене клацання правою кнопкою миші на.

Зазвичай для великих проектів база даних вже створена. Або тому, що це застаріла база даних або створена компетентною dba для продуктивності. Єдина користь від CodeFirst полягає в тому, що ви не хочете використовувати об'єкти EF, а замість них POCO.

Мені це здається, що "Код по-перше" призначений для використання EF з більш "спритним" (не гуляйте занадто сильно на цьому терміні, я не обов'язково маю на увазі методологію) та greenfield-додатків, де у вас немає існуюча модель даних або існуючі дані; такий додаток, яким ви також могли б користуватися Django, або PHP-рамкою, або Rails для дотримування тих вказівок фреймворку, які зазвичай передбачають створення моделі даних як частини коду, а не побудову програми навколо моделі даних, яка є традиційною Microsoft спосіб поводження з речами.

Отже, щоб відповісти на запитання, я сказав би «ні»; якщо у вас вже є дані і ви створюєте додаток для їх обробки, Code First не має великого сенсу. Однак, і я зовсім не дуже використовував EF, не кажучи вже про Code First EF, здається, що це більш вільно пов'язаний підхід до коду, який завжди вигідний. Якщо припустити, що ви можете використовувати Code First, а потім все-таки вказати клас на існуючу модель даних (замість того, щоб змушувати генерувати модель), підхід Code First все ще може допомогти написати правильно абстрагований і перевірений код без усього звичного "суворого" використання Entity Framework (тобто створені метакласи).

Я б сказав, що в дійсно великих проектах кодування спершу не має сенсу.

Насправді, коли проект стає дійсно масштабним, у вас часто виникає чітке розмежування проблем. У вас не може бути одна людина, яка пише код C #, займається дизайном баз даних, пише HTML / CSS та робить візуальний дизайн у Photoshop. Натомість проектуванням баз даних займається адміністратор бази даних (або принаймні спеціальна особа, яка знає її роботу).

Оскільки база даних розроблена особою, яка знайома з базою даних, SQL, адміністрацією та засобами проектування баз даних, було б дивно бачити цю людину за допомогою Entity Framework.

Більше того, я не впевнений, чи є Entity Framework достатньо потужним, щоб правильно створити базу даних. Що з індексами? Обмеження? Перегляди?

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