Code-First или Database-First, как выбрать?
Давайте предположим, что мы собираемся начать новый проект - приложение, которое содержит некоторую бизнес-логику, пользовательский интерфейс на ASP.NET, WPF или их обоих. Мы хотели бы использовать генератор кода ORM или DAL и реализовать нашу бизнес-логику в классах.NET. Существует несколько основных способов выражения наших идей в области бизнеса:
- Реализуйте бизнес-классы в.NET и позвольте ORM генерировать соответствующую схему базы данных
- Создайте схему базы данных вручную и сгенерируйте классы.NET с помощью генератора кода
- Используйте какой-нибудь визуальный дизайнер, который может генерировать бизнес-классы и структуру базы данных или скрипт
Что вы предпочитаете писать: "Создать табличных людей ( ...)" или "открытый класс Person { ... }"?
Каковы плюсы и минусы этих способов?
Может быть, есть особые ситуации, когда один путь лучше другого?
Как выбрать оптимальный путь в конкретном проекте?
Я хорошо знаком с способом "Code-First" (или "Model-First"), но кажется, что большинство ORM спроектированы как генераторы или преобразователи кода, которые предполагают, что я буду вручную реализовывать как структуру базы данных, так и бизнес-классы.
Ответы, основанные на опыте и примерах ORM, особенно приветствуются.
Изменить: Обратите внимание, вопрос не в том, "Что мне делать в первую очередь при запуске нового проекта?", А в том, "Что должно быть объявлено / автоматически сгенерировано, классы домена или структура базы данных?"
11 ответов
Я думаю, что подходящий подход к системному анализу и проектированию - начать с моделирования ваших объектов и отношений между ними в первую очередь. Если вы создаете библиотечную систему, вы должны думать о фразах Book, Author, Publisher, ISBN как об объектах, а не о таблицах или атрибутах базы данных. Я считаю, что так и должно быть. Тем не менее, давайте признаем, что генераторы кода экономят много времени, а для них требуется реляционная база данных, чтобы сгенерировать модель и сопоставить ее с объектами БД. Я думаю, что это основная причина, по которой разработчики склонны начинать с БД. Что может доказать мою точку зрения, так это то, что разработчики генераторов кода стараются полностью изменить текущую реализованную операцию (т. Е. Вы предоставляете бизнес-модель - объекты и классы - и генератор создает БД с соответствующей схемой для этого).
Редактировать:
Вот пример генераторов первого домена (сама ADO.NET Entity Framework) Model First:
Visual Studio 2010 имеет возможность генерировать DDL и создавать базу данных для хранения модели данных объекта. Разработчик имеет полный контроль над всем процессом, имея возможность настраивать DDL, или выбирать базу данных, которую он желает, или точно настраивать процесс отображения.
Почему не интерфейс первый?
Слишком много приложений начинаются с менталитета программы. Это плохая идея. Программирование - это самый тяжелый компонент построения приложения, то есть оно самое дорогое и сложное для изменения. Вместо этого начните с проектирования в первую очередь.
Дизайн относительно легкий. Бумажный набросок дешевый и его легко заменить. HTML-дизайны все еще относительно просты для изменения (или выбрасывания). Это не относится к программированию. Во-первых, дизайн делает вас гибким. Программирование сначала защищает вас и настраивает на дополнительные расходы.
Это из Главы 9 Получение Реала 37signals.
"Покажи мне свои блок-схемы и спрячь свои таблицы, и я буду продолжать мистифицироваться. Покажите мне свои таблицы, и мне обычно не нужны ваши блок-схемы; они будут очевидны.
- Фред Брукс в "Мифическом человеко-месяце"
На мой взгляд, нет правильного ответа на это. Я думаю, это в основном сводится к вашим личным предпочтениям или предпочтениям вашей команды. Все упомянутые подходы (сначала база данных, сначала код, сначала интерфейс) имеют свои преимущества и недостатки.
Вероятно, я бы сел с ручкой и бумагой и набросал общую структуру и основные функции приложения, прежде чем делать что-то конкретное, будь то код или таблицы базы данных. Простое рисование основного пользовательского интерфейса также очень помогает.
В большинстве случаев это не имеет большого значения. Это больше зависит от личных предпочтений и навыков, чем все остальное. Большинство приложений не сильно пострадают в любом случае, используйте то, что нравится вашей команде. Там, где выбор действительно важен, должно быть очевидно, какой подход выбрать.
Тем не менее, мое личное мнение таково, что "база данных сначала", как правило, более безопасный выбор. Если данные каким-либо образом важны, особенно если они важны за пределами вашего конкретного приложения, вы хотите иметь полный контроль над тем, как они хранятся.
"Сначала код" (подразумевается: оставить базу данных в руках какого-то автоматического инструмента), на мой взгляд, является ярлыком, который вы должны использовать, когда (и только когда) вы точно знаете, что с этим можно обойтись.
Чтобы ответить на ваш отредактированный вопрос (ручные классы db/auto или ручные классы /db), я бы выбрал "ни один". Автогенерируемый код обоих видов следует избегать по ряду причин, прежде всего YAGNI. В итоге вы получите код, который никогда не писали, но тем не менее несете ответственность, код, который вы никогда не будете использовать, и (по моему опыту) код, в конечном итоге вы потратите больше времени на рефакторинг, чем если бы вы разработали и написали его самостоятельно в первом место. И оба они держат ваш фокус далеко от самого важного места - пользователя.
Сначала анализ требований, а затем некоторая документация этих потребностей и обзор аспектов данных этого?
Затем вы знаете, какие данные вы будете собирать и как они связаны с другими данными, и сможете разработать схему базы данных или структуру данных для ее сопоставления (в виде логических объектов / таблиц с соответствующим содержимым, а не "tab1_data", "tab2_data", соответствующих процесс сбора данных, который может измениться, но вы это знаете!). Вы могли бы даже спроектировать.xsd сначала и сгенерировать код и схему базы данных из этого. В наши дни все весело и игры, в зависимости от ваших навыков.
Поскольку схема базы данных в моей памяти хранит данные, и это действительно важная вещь для бизнеса, я спроектировал бы это в первую очередь - несколько инструментов могут получить к ней доступ вовремя, возможно, оригинальная система будет заменена на линию (например,, переход на новые инструменты / языки / интерфейсы). Если вы ничего не знаете о теории баз данных, то, возможно, это не самый лучший вариант, но я все равно получу проверку любой сгенерированной схемы кем-то другим.
Доменное моделирование против реляционного моделирования
Есть несколько основных способов, как мы можем выразить наши идеи бизнес-сферы
Я думаю, что важно сначала установить, что домен не зависит от конкретных технологий и / или парадигм программирования (например, OO, FP, реляционный). В этом ответе предполагается, что вы уже определили свой домен отдельно, например, с помощью методов DDD, и теперь хотите использовать реляционную базу данных для его хранения.
Сильные стороны реляционной модели
Реляционная модель была изобретена, среди прочих причин, для устранения многих проблем, которые были вызваны предыдущими моделями, включая сетевую модель (которая включает в себя модели OO), иерархическую модель (которая включает модели XML/JSON) или простой ключ. стоимость магазинов. У этого есть много преимуществ по всем альтернативам, которые сделали это настолько популярным в течение многих десятилетий.
На мой взгляд, эти сильные стороны указывают на то, что вы должны создать свою модель базы данных внутри базы данных, которая была создана именно для этой цели. Все остальные модели, включая вашу клиентскую модель, являются копиями этой оригинальной реляционной модели из базы данных. Таким образом, все остальные модели должны быть получены из него, а не источник для него.
Рассматривайте реляционную модель, выраженную в DDL, как источник истины
XSD такой же
XML/XSD - похожая технология. Ваши данные выражаются в терминах XML, но когда две системы взаимодействуют друг с другом через API на основе XML, XSD (или, например, WSDL, если хотите) является наиболее подходящим языком для определения этой связи.
Если вы хотите привязать свои XML-документы с помощью клиентской технологии, например, JAXB в Java, то вы должны сгенерировать эти классы JAXB из XSD, а не наоборот. Зачем? Потому что XSD является источником правды
Начните с того, что вы не будете напрямую думать о "модели" (желательно на бумаге), какие части будут иметь ваше приложение с точки зрения пользователей.
Если у вас есть четкое представление об этой модели, вы можете разделить части на общие и конкретные маленькие элементы, которые вы можете перевести как в определения объектов, так и в таблицы базы данных.
Я считаю, что этот метод позволяет значительно сократить время и усилия по нормализации базы данных.
Лично мне нравится контроль над созданием объектов RDBMS. Когда я сначала использую код EF, он фактически создает больше работы для базовых вещей, таких как отношения таблиц и т. Д., Которые большинство приличных генераторов кода делает для вас из коробки (я знаю, в этом идея... больше контроля над вашими моделями!), Кроме того, идея, что EFCF будет генерировать БД, как я надеюсь, немного страшна. (Традиционно код развивается легче, чем RDMBS!)
Для системы, которая требует постоянного развития (например, SaaS), и, как правило, большой системы уровня предприятия с 500 + таблицами и т. Д., Это может быть менее привлекательным предложением. С другой стороны, если у вас есть правильный проект базы данных SQL Server 2008 со всеми таблицами, сценариями SP, триггерами, индексами, и вы можете развернуть их из Visual Studio, это намного более управляемо. Теперь у вас есть свобода использования любого кода, который вы хотите для своих таблиц (даже создать свой собственный)
Вы не привязаны к On Framework (EFCF), после чего вы можете использовать разные ORM (например, NHibernet) в зависимости от требований вашего "мини" проекта в вашей большой системе.
Есть 3 важных аспекта, которые необходимо учитывать при разработке приложения базы данных...
- Пользовательский опыт
- Качество данных
- Стоимость поддержки первых двух (пользовательский опыт и качество данных)
Я полагаю, что приоритет этих трех элементов выражается в порядке их представления, то есть наивысшим приоритетом является пользовательский опыт, вторым по важности является качество данных, а третьим - это стоимость. Конечно, это может быть обсуждено, но понятие кода сначала или базы данных сначала относится к третьему приоритету - стоимости. Каким бы ни был выбор - сначала напишите код или базу данных, убедитесь, что выполнены первые два приоритета...