.net - Code-First or Database-First，如何选择？

Question

让我们假设我们要开始新项目 - 包含一些业务逻辑的应用程序、ASP.NET 上的用户界面、WPF 或两者。我们想使用 ORM 或 DAL 代码生成器并在 .NET 类中实现我们的业务逻辑。我们可以通过几种基本方式来表达我们对业务领域的想法:

• 在 .NET 上实现业务类并让 ORM 生成适当的数据库模式
• 手动创建数据库模式并通过代码生成器生成 .NET 类
• 使用某种可视化设计器，可以生成业务类和数据库结构或脚本

你更喜欢写什么:“Create Table Persons ( ... )”或“public class Person { ... }”？
这些方式的优缺点是什么？
也许在某些特殊情况下，一种方式比另一种方式更好？
如何在特定项目中选择最佳方式？

我非常熟悉“代码优先”(或“模型优先”)方式，但似乎大多数 ORM 都被设计为代码生成器或映射器，假设我将手动实现数据库结构和业务类.

特别欢迎基于经验和 ORM 示例的回答。

编辑:注意，问题不是“开始新项目时我应该首先做什么？”，而是“应该手动声明/自动生成什么，域类或数据库结构？”

Answer 1

我认为进行系统分析和设计的合适方法是首先对您的对象及其之间的关系进行建模。如果您正在创建图书馆系统，您应该将 Book、Author、Publisher、ISBN 等短语视为对象，而不是数据库表或属性。我相信这是应该的方式。话虽如此，我们承认代码生成器可以节省很多时间，而代码生成器需要关系数据库才能生成模型并将其映射到数据库对象。我认为这是开发人员倾向于从 D.B. 开始的主要原因。更能证明我的观点的是，代码生成器开发人员正在努力扭转当前实现的操作(即，您提供业务模型 - 对象和类 - 生成器为此创建具有适当模式的数据库)。

编辑:
这是 domain-first generators (ADO.NET Entity Framework itself) Model First 的示例:

Visual Studio 2010 has to ability to generate a DDL and create a database to store the entity data model. The developer has complete control over the entire process being able to customize the DDL, or to select the database he desires, or fine tune the mapping process.