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

Question

Предположим, мы собираемся запустить новый проект - приложение, содержащее некоторую бизнес-логику, пользовательский интерфейс в ASP.NET, WPF или оба из них. Мы хотели бы использовать генератор кода ORM или DAL и реализовать нашу бизнес-логику в классах .NET. Существует несколько основных способов выражения наших идей в области бизнеса:

• Реализация бизнес-классов в .NET и позволить ORM генерировать соответствующую схему базы данных
• Создание схемы базы данных вручную и создание классов .NET с помощью генератора кода
• Используйте какой-нибудь визуальный дизайнер, который может генерировать бизнес-классы и структуру базы данных или скрипт

Что вы предпочитаете писать: «Создать табличных людей (...)» или «открытый класс Person {...}»?
Каковы плюсы и минусы этих способов?
Может быть, есть особые ситуации, когда один путь лучше другого?
Как выбрать оптимальный путь в конкретном проекте?

Я хорошо знаком с способом «Code-First» (или «Model-First»), но кажется, что большинство ORM спроектированы как генераторы кода или преобразователи, которые предполагают, что я буду вручную реализовывать как структуру базы данных, так и бизнес-классы .

Особенно приветствуются ответы, основанные на опыте и примерах ORM.

Редактировать: Обратите внимание: вопрос не в том, «Что мне делать в первую очередь при запуске нового проекта?», А в том, «Что должно быть объявлено / автоматически создано, классы домена или структура базы данных?»

Answer 1

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

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

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