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

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

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

Answer 4

在我看来，没有正确的答案。 我想这主要归结为你个人或团队的偏好。 所有提到的方法（数据库优先，代码优先，接口优先）都有各自的优缺点。

在我做任何特定的事情之前，我可能会用笔和纸坐下来勾勒应用程序的一般结构和主要功能，无论是代码还是数据库表。 基本用户界面的简单绘图也有很大帮助。

Answer 5

首先分析需求，然后对这些需求进行一些记录并对数据方面进行概述？

然后你知道你将捕获哪些数据以及它与其他数据的关系，并且可以设计数据库模式或数据结构以匹配它（作为相关内容的逻辑对象/表，而不是“tab1_data”，“tab2_data”匹配数据捕获过程可能会改变，但你知道！）。 你甚至可以先设计一个.xsd，然后从中生成代码和数据库模式。 这些天都很有趣，这取决于你的技能。

由于我脑海中的数据库模式存储数据，这对于企业来说非常重要，我会先设计 - 多个工具可以及时访问它，也许原始系统会被替换掉（例如，迁移到更新的工具/语言/接口）。 如果您对数据库理论一无所知，那么这可能不是您的最佳选择，但我仍然会得到其他人验证的任何生成的模式。

Answer 6

在大多数情况下，它并不重要。 这取决于个人偏好和技能，而不是其他任何东西。 大多数应用程序不会受到任何影响，使用您的团队所熟悉的任何内容。 选择真正重要的地方应该明确哪种方法。

也就是说，我个人认为“数据库优先”通常是更安全的选择。 如果数据在任何方面都很重要，特别是如果数据在特定应用程序范围之外很重要，那么您希望完全控制数据的存储方式。

“代码优先”（暗示：将数据库留在一些自动工具的手中）在我的脑海里真的是一个快捷方式，你应该使用的时候（并且只有当你知道）你可以侥幸逃脱它。

Answer 7

要回答你编辑过的问题（手动db / auto classes或manual classes / db），我选择“both”。 出于多种原因，首先要避免两种类型的自动生成代码，首先是YAGNI。 你最终得到了你从未写过的代码，但仍然负责，你永远不会使用的代码，以及（根据我的经验）代码，你最终会花费更多的时间进行重构，而不是你自己设计和编写的代码。地点。 而且他们都将焦点远离最重要的位置 - 用户。

Answer 8

域建模与关系建模

我们可以通过几种基本方式表达我们的业务领域

我认为首先确定域独立于具体技术和/或编程范例（例如OO，FP，关系）是很重要的。 这个答案将假设您已经单独定义了您的域，例如使用DDD实践，现在希望使用关系数据库来存储它。

关系模型的优势

除了其他原因之外，发明了关系模型，以消除由先前模型引起的许多问题，包括网络模型 （包括OO模型）， 分层模型 （包括XML / JSON模型）或简单密钥超值商店。 它在所有替代方案上都有很多优势，这使它几十年来如此受欢迎。

在我看来，这些优势表明，你应该设计的数据库，该数据库已经取得了正是为此目的的内部数据库模型。 所有其他模型（包括客户端模型）都是数据库中原始关系模型的副本。 因此，所有其他模型都应该来自它，而不是它的来源 。

请参阅以DDL表示的关系模型作为您的真实来源

XSD是一样的

XML / XSD是一种类似的技术。 您的数据以XML表示，但当两个系统通过基于XML的API相互通信时，XSD（或WSDL，如果您需要）是指定该通信的最合适的语言。

如果您想使用客户端技术（例如Java中的JAXB）绑定到XML文档，那么您应该从XSD生成这些JAXB类，而不是相反。 为什么？ 因为XSD是事实的来源

我在这里写过这个主题 。

Answer 9

首先，不要直接考虑任何一种，而是“模型”（最好在纸上）从应用程序的角度来看应用程序将具有哪些部分。

如果您对该模型有清晰的心理图像，则可以将这些部分分成共同的特定小元素，您可以将它们转换为对象定义和数据库表。

我发现这种方法可以显着缩短数据库规范化时间和精力。

Answer 10

就个人而言，我喜欢控制创建RDBMS对象。 当我首先使用EF代码时，它实际上为基本的东西创建了更多的工作，例如表关系等，大多数不错的代码生成器为你开箱即用（我知道这个想法......更多控制你的模型！） 。 另外，我希望EFCF会生成数据库的想法有点可怕。 （传统上Code比RDMBS更容易发展！）

对于需要不断发展的系统（例如SaaS），以及通常具有500 +表等的大型企业级系统，其可能不那么吸引人的主张。 另一方面，如果您有一个适当的SQL Server 2008数据库项目，其中包含所有表，SP，触发器，索引脚本，并且您可以从Visual Studio部署它们，那么它就更容易管理。 您现在可以自由地使用您想要的任何代码表（甚至构建自己的代码）

您不依赖于框架（EFCF），然后您可以使用不同的ORM（例如NHibernet），具体取决于您的大型系统中的“迷你”项目要求。

Answer 11

在开发数据库应用程序时需要考虑3个重要方面......

1. 用户体验
2. 数据质量
3. 维持前两个的成本（用户体验和数据质量）

我相信这三个项目的优先级以它们的呈现顺序表示，这意味着最高优先级是用户体验，第二个优先级是数据质量，第三个是这样做的成本。 当然这些可以辩论，但首先是代码或数据库的概念是相对于第三优先级 - 成本。 无论选择什么 - 首先是代码或首先是数据库，确保满足前两个优先级......