Code-First или Database-First, как выбрать?

Ответ 1

Я думаю, что подходящий подход к системному анализу и дизайну должен начинаться с моделирования ваших объектов и отношений между ними. Если вы создаете библиотечную систему, вы должны думать о фразах Book, Author, Publisher, ISBN как о объектах, а не о таблицах или атрибутах базы данных. Я считаю, что так оно и должно быть. Это было сказано, позвольте признать, что генераторы кода экономят много времени, а для них требуется реляционная база данных, чтобы сгенерировать модель и сопоставить ее с объектами БД. Я думаю, что это основная причина, по которой разработчики склонны начинать с D.B. Что еще может доказать, что разработчики генераторов кода стараются отменить текущую операцию (т.е. Вы предоставляете объекты бизнес-модели и классы, а генератор создает базу данных с соответствующей схемой для этого).

Изменить:
Здесь приведен пример генераторов доменных имен (сама СУБД ADO.NET) Первая модель:

Visual Studio 2010 должна иметь возможность генерировать DDL и создавать базу данных для хранения модели данных сущности. Разработчик имеет полный контроль над всем процессом, который может настроить DDL, или выбрать нужную ему базу данных, или точно настроить процесс сопоставления.

Ответ 2

Почему не интерфейс сначала?

Слишком много приложений начинается с менталитета программы. Это плохая идея. Программирование - самый тяжелый компонент построения приложения, что означает, что это самый дорогой и сложнейший вариант для изменения. Вместо этого начните сначала с разработки.

Конструкция относительно легкая. Эскиз бумаги дешевый и легко меняющийся. html-проекты по-прежнему относительно просто изменить (или выбросить). Это не относится к программированию. Сначала проектирование держит вас гибким. Программирование первых заборов и внесение дополнительных затрат.

Это из Глава 9 Получение прав от 37signals.

Ответ 3

"Покажите мне свои блок-схемы и сокрыте свои столы, и я буду продолжать мистифицировать. Покажите мне ваши столы, и мне обычно не нужны ваши блок-схемы, они будут очевидны".

- Фред Брукс в "Мифическом человеке-месяце"

Ответ 4

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

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

Ответ 5

Сначала проанализируйте требования, а затем некоторую документацию по этим потребностям и обзор аспектов данных этого?

Затем вы знаете, какие данные вы будете захватывать и как они относятся к другим данным, и могут проектировать схему базы данных или структуру данных для ее соответствия (как логические объекты/таблицы связанного контента, а не "tab1_data", "tab2_data" "соответствующий процесс захвата данных, который может измениться, но вы это знаете!). Вы даже могли бы сначала создать .xsd и сгенерировать код и схему базы данных. Все это весело и игры в эти дни, в зависимости от вашего набора навыков.

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

Ответ 6

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

Тем не менее, мое личное мнение заключается в том, что сначала "база данных" - это более безопасный выбор. Если данные каким-либо образом важны, особенно если это важно вне сферы вашего конкретного приложения, вы хотите иметь полный контроль над тем, как он хранится.

"Сначала код" (подразумевается: оставляя базу данных в руках некоторого автоматического инструмента), на мой взгляд, действительно ярлык, который вы должны использовать, когда (и только когда) вы знаете наверняка, что сможете с ним справиться.

Ответ 7

Чтобы ответить на отредактированный вопрос (ручные классы db/auto или ручные классы /db ), я бы выбрал "ни один". Автогенерированный код обоих видов следует избегать по ряду причин, в первую очередь YAGNI. Вы в конечном итоге получаете код, который вы никогда не писали, но тем не менее отвечаете за код, который вы никогда не будете использовать, и (по моему опыту) код вы в конечном итоге потратите больше времени на рефакторинг, чем если бы вы разработали и написали его сами в первом место. И они оба держат ваш фокус далеко от самого важного места - пользователя.

Ответ 8

Начните с того, что не задумывайтесь об этом, а скорее о "модели" (желательно на бумаге), какие части вашего приложения будут иметь с точки зрения пользователей.

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

Я нахожу этот метод значительно сократить время и усилия по нормализации базы данных.

Ответ 9

Лично мне нравится управлять созданием объектов РСУБД. Когда я сначала использую EF-код, он фактически создал больше работы для основных вещей, таких как отношения таблиц и т.д., Которые наиболее достойные генераторы кода делают для вас из коробки (я знаю, что идея... больше контроля над вашими моделями!), Также Идея, что EFCF будет генерировать db, как я надеюсь, немного страшен. (традиционно Code развивается легче, чем RDMBS!)

Для системы, которая требует постоянного развития (например, SaaS) и, как правило, крупной системы Enterprise Level с таблицами 500 + и т.д., ее может быть менее привлекательным предложением. С другой стороны, если у вас есть соответствующий проект базы данных SQL Server 2008 со всеми таблицами, сценариями SP, триггерами, индексами, и вы можете развернуть их из Visual Studio гораздо более эффективно. Теперь у вас есть свобода использования любого кодегана, который вы хотите для своих таблиц (даже создайте свой собственный).

Вы не привязаны к платформе on (Framework) (EFCF), тогда вы можете использовать разные ORM (NHibernet, например, в зависимости от вашего проекта) в вашей большой системе.

Ответ 10

Есть 3 важных аспекта, которые необходимо учитывать при разработке приложения базы данных...

• Пользовательский опыт
• Качество данных
• Стоимость поддержки первых двух (пользовательский опыт и качество данных)

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