【发布时间】：2011-03-02 15:22:47
【问题描述】：
在数据库驱动的 asp.net web 应用程序流程中，最好的方法或推荐的最佳实践是什么？我的意思是先数据库还是先编码还是并排？
【问题讨论】：
【发布时间】：2011-03-02 15:22:47
【问题描述】：
如果没有现有数据库，您的数据访问代码将无法编译 - 除非您存根（或模拟）它。所以可能数据库是第一位的。
但是孤立地执行整个应用程序块是一个坏主意。理想情况下，您应该携手设计和构建系统的各个部分——数据库和应用程序。这些条子应该是功能的内聚子集，可能比子系统小。不可避免地，编码屏幕和业务规则的行为会在数据模型中引发问题。因此，最好有一名数据建模师或 DBA 乐于与开发人员一起逐步开展工作。
编辑
斯蒂芬妮提出了一个非常中肯的观点：
" 持久化的核心表 你的应用程序的数据真的不能 零碎的。大部分数据是已知的 在项目开始时。它有一个形式，你 需要找到它。”
我同意核心实体在项目开始时是已知的，并且物理数据模型可以从该逻辑数据模型导出。但我认为，从一开始就不可能完全确定任何表的结构，甚至是核心表。这是因为在设计/构建阶段开始时，我们所要做的就是需求，如果历史告诉我们关于需求的一件事，那就是它们会改变。
因此，将需要新表，而一些现有表将过时。会有需要添加的列，需要修改的列，需要删除的列。这就是 Nature 给我们 ALTER TABLE 语句的原因。
我并不是建议我们不要设计我们的桌子，或者把它们拼凑起来。我只是建议，当我们开始设计 HR 子系统时，我们需要考虑 EMPLOYEES 表和 SALARIES 表。在我们开始销售工作之前，我们不需要关心库存或订单。
【讨论】：
-
我同意需要一些迭代。我完全不同意您应该构建数据模型的“碎片”。是的，您可能忘记了某个表上的标志，或者您需要一些处理表，但是保存应用程序数据的核心表确实不能零碎。大多数数据在项目开始时是已知的。它有一个表格，你需要找到它。如果大部分数据不为人所知，那么您已经把自己搞砸了“我无法收集需求，我有太多代码要编写”的口头禅。
-
什么时候数据访问代码在没有数据库的情况下无法编译？ :)
应用程序都是关于功能的。 您不会构建应用程序来存储数据， 但要提供功能。要是我们 不能同意，讨论是 当然没有实际意义。软件应该是 开发以满足其需求 用户而不是其开发人员。
嗯，我真的不明白第二句话。如果你认为我的公司付给我高薪来编写让我满意而不是让我的用户满意的代码，那你就疯了。所以这个论点是稻草人。回到第一个。
这是以应用程序为中心的人（他们）与以数据库为中心的人（我们）的共同观点。他们看到了“提供功能”这一练习的全部意义。这些是客户知道他们想要并要求他们做的事情。对他们来说，数据库只是这些特性所需的持久性。当它们完成时，就是这样，交付的功能，数据库对于这些功能就足够了。可能是数据库中的整个 Rube Goldberg，其中包含冗余数据、严重违反规范形式、应用程序强制执行的约束，你有什么。
认为整体可用性比数据库设计更重要
如果您的数据库设计影响了您的可用性，那么设计就是糟糕的。我毫不怀疑，追求功能的人会使数据库处于严重影响可用性的状态。
以数据为中心的人，不要将系统视为只提供所要求的东西的地方，而是一个知识资本的存储库，可以被更多的应用程序所利用。我无法描述一个团队使用其他团队应用程序的数据库来提高其应用程序价值的案例数量。看看所有医学研究，只不过是对现有研究的荟萃分析。如果您认为只有应用的功能和应用数据的后续使用无关紧要，那么这一切都是不可能的。
良好的数据模型并非不可侵犯。当然你会添加它，当需求改变时改变它。但是如果你不完全理解你的数据，我不知道任何人都可以开始编写代码。
【讨论】：
-
由于 @back2dos 昨天删除了他们的评论，这篇文章不再有意义，因为它并没有真正解决 OP 的担忧。
-
+1
if you don't completely understand your data, I don't know how anyone can begin to write code.
这是一个棘手的问题。 IMO，它们在您的规划和设计阶段同时出现。它们是如此密切相关，因此将它们一起做是有意义的。请记住，您的数据库设计将几乎完全开发，而您的代码仍处于起步阶段（尽管您的应用程序逻辑应该几乎完全映射在您的脑海或纸上）
这个想法是您在问题的背景下设计您的解决方案。当您计划解决方案时，您将（或应该）将您的应用程序定义为一组事物和动作（名词和动词）。
例如，一个非常基本的帮助台程序有人员和工单。人们需要创建工单、更新工单和关闭工单。需要持久存储的名词将构成您的数据库，而名词 + 动作将包含在您的应用程序中。
有时您的表映射和表之间的关系会很明显（即人们创建工单，ticket.creatorID = people.personID），而在其他时候，直到您开始研究用例或直到您开始编写代码（IE 不同的 ppl 具有不同的访问级别来定义他们可以做什么。乍一看，这似乎是表中的一个简单字段，但实际上它作为一个单独的表更好）。
【讨论】：
做了很多次之后，我发现自己总是这样：
- 定义我要解决的问题。
- 写出一些用例。
- 让我的另一半或朋友告诉我这是否是个问题。
- 画出几个示例屏幕。
- 为用例编写流程图。
- Ask my Rubber-duck questions。
- 使用问题细化 1-6。
- 写出“名词”。这些成为我的数据模型。
- 写出动作。这些成为应用程序逻辑。
- 代码数据模型。
- 代码应用逻辑。
- 意识到我弄错了。
- 根据需要重复 10-12 次。
- 问，“我解决了这个问题吗？”
- 如果没有，请冲洗、起泡并重复 1-15。
【讨论】：
-
爱第6步！给了我一个傻笑。
-
我喜欢它。 （还需要 4 个字符才能发表完整评论）
我们亲自从域开始，并肩做事。重要的部分是我们实现应用程序的垂直切片（完全工作的端到端功能），而不是水平切片（例如，首先是整个数据库层，然后是数据访问，然后是服务，然后是演示）：我们逐步构建应用程序，并在每次迭代后展示工作代码的进度。
【讨论】：
你可能最终会“并排”做这件事。
您需要一些数据才能测试应用程序，但您需要应用程序能够验证您存储的数据是否正确。
先做一些建模，然后为一两个功能构建尽可能少的模型。然后当这些工作时添加下一个功能等等。
您需要编写一些数据库更新程序（包括代码和更新内容和时间的规则），因为您必须扩展您的表，但最终系统仍然需要这些程序，因为它会必须随着新要求的出现而改变。
【讨论】：
首先是功能列表。 然后，详细的规格。 然后测试所有的计划和设计，包括数据库。
那么，先实现哪个并不重要。
【讨论】：
-
我们不是在讨论先实现什么，而是先设计什么。
我想您需要先定义数据模型，然后再进行编码。在实际编写代码之前，您应该仔细计划一切。
【讨论】：