Code-First或Database-First,如何选择？

Question

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

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

您更喜欢写什么:"创建表人(...)"或"公共类人{...}"？
这些方式的优点和缺点是什么？
也许有一些特殊的情况,一种方式比另一种更好？
如何在特定项目中选择最佳方式？

我对"Code-First"(或"Model-First")方式非常熟悉,但似乎大多数ORM都设计为代码生成器或映射器,假设我将手动实现数据库结构和业务类.

基于expirience的答案和ORM的例子特别受欢迎.

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

Answer 1

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

编辑:
以下是域优先生成器(ADO.NET实体框架本身)模型的示例:

Visual Studio 2010必须能够生成DDL并创建数据库以存储实体数据模型.开发人员可以完全控制整个过程,可以自定义DDL,或者选择他想要的数据库,或者微调映射过程.

Answer 2

为什么不先接口？

太多的应用程序以程序优先的心态开始.这是个坏主意.编程是构建应用程序最重要的组成部分,这意味着它是最昂贵且最难改变的.相反,首先要先设计.

设计相对较轻.纸质草图便宜且易于更改.HTML设计仍然比较容易修改(或丢弃).编程并非如此.先设计让您保持灵活性.编程首先围绕您,并为您安排额外费用.

这是来自37signals 的Get Real的第9章.

Answer 3

"告诉我你的流程图并隐藏你的桌子,我将继续神秘化.告诉我你的桌子,我通常不需要你的流程图; 他们会很明显."

- 弗雷德布鲁克斯在"神话人月"