首先是：数据库或应用程序逻辑？

Question

数据库驱动的asp.net Web应用程序流程中最好的方法或推荐的最佳实践是什么？我的意思是数据库第一个或首先编码或并排编码？

Answer 1

如果没有现有数据库，您的数据访问代码将无法编译 - 除非您存根（或模拟）它。所以数据库可能是第一位的。

但是，孤立地完成应用程序的整个块是个坏主意。理想情况下，您应该设计和构建系统的细分 - 数据库和应用程序 - 手拉手。这些细长条应该是有凝聚力的功能子集，可能比子系统小。编码屏幕和业务规则的行为不可避免地会引发数据模型中的问题。因此，拥有一名愿意与开发人员一起逐步增加工作的数据建模者或DBA是件好事。

修改

斯蒂芬妮提出了一个非常恰当的观点：

  

“坚持的核心表格   你的应用程序的数据真的不可能   piecemealed。大多数数据都是已知的   在项目开始。它有一个表格，你   需要找到它。“

我同意核心实体在项目启动时是可知的，物理数据模型可以从该逻辑数据模型中导出。但我不认为有可能在一开始就完全确定任何表格的结构，甚至是核心表格。这是因为在设计/构建阶段的开始阶段，我们所要做的就是需求，如果历史记录告诉我们有关需求的一件事，那么就会改变。

因此，将需要新表，并且一些现有表将变得过时。将需要添加列，需要修改的列，需要删除的列。这就是为什么大自然给了我们ALTER TABLE语句。

我并不是说我们不设计我们的桌子，也不是零碎地组装它们。我只是建议当我们开始设计HR子系统时，我们需要担心EMPLOYEES表和SALARIES表。在我们开始销售工作之前，我们不需要关心INVENTORY或ORDERS。

Answer 2

我们亲自从域开始，并肩并肩做事。重要的是我们实现了应用程序的垂直切片（完全工作的端到端功能），而不是水平切片（例如，首先是整个数据库层，然后是数据访问，然后是服务，然后是演示文稿）：我们逐步构建应用程序，并在每次迭代后演示使用代码的进度。

Answer 3

  

应用程序都是关于功能的。   您不构建应用程序来存储数据，   但要提供功能。要是我们   不能就此达成一致，讨论是   当然没什么。软件应该是   开发以满足其需求   用户而非开发者。

我真的不理解第二句话。如果你认为我的公司付给我很高的薪水来编写令我满意的代码，而不是我的用户那么你就疯了。所以这个论点是一个稻草人。回到第一个。

这是以应用程序为中心的人（他们）与以数据库为中心的人（我们）的共同观点。他们认为演习的全部内容都是“提供功能”。这些是客户知道他们想要的东西并要求他们。对他们来说，数据库只是这些功能所需的持久性。当它们完成时，就是它，提供的功能，数据库就足以满足这些功能。可能是数据库中的整个Rube Goldberg，包含冗余数据，严重违反正常形式，应用程序强制执行的约束，你有什么。

  

认为整体可用性超过了数据库设计

如果数据库的设计影响了您的可用性，那么设计就不好了。我毫不怀疑，那些努力争取功能的人会让数据库处于严重妨碍可用性的状态。

以数据为中心的人，不要将系统视为仅提供所要求内容的地方，而是将智力资本的存储库视为可以被应用程序开发的更多内容。我无法开始描述一个团队使用其他团队应用程序的数据库来增强其应用程序价值的案例数量。只要看看所有的医学研究，这些研究只不过是现有研究的荟萃分析。如果您认为只有应用功能的重要性以及应用数据的后续使用情况，那么这一切都无法实现。

良好的数据模型不是不可侵犯的。当然你会添加它，在需求变化时更改它。但是如果你不完全理解你的数据，我不知道任何人都可以开始编写代码。

Answer 4

我想您首先需要定义数据模型，然后再进行编码。在实际编写代码之前，您应该仔细规划所有内容。

Answer 5

首先是功能列表。 然后，详细的规格。 然后测试所有计划和设计，包括数据库。

然后，首先实施哪个无关紧要。

Answer 6

你可能最终会“并排”地做到这一点。

您需要一些数据才能测试应用程序，但您需要应用程序能够验证您是否存储了正确的数据。

首先进行一些建模，然后为一个或两个功能构建最小值。然后当这些工作正常时，添加下一个功能，依此类推。

你需要编写一些数据库更新程序（代码和关于什么以及什么时候更新的规则），因为你必须扩展你的表，但是无论如何你都需要最终系统的那些，因为它会必须随着新要求的出现而改变。

Answer 7

做了好几次后，我发现自己总是这样做：

1. 定义我正在尝试解决的问题。
2. 写出一些用例。
3. 让我的重要的其他人或朋友告诉我这是否是一个问题。
4. 草拟一些示例屏幕。
5. 编写用例的流程图。
6. Ask my Rubber-duck questions。
7. 使用问题来优化1-6。
8. 写出'名词'。那些成了我的数据模型。
9. 写出行动。那些成了应用逻辑。
10. 代码数据模型。
11. 代码应用逻辑。
12. 意识到我有点不对劲。
13. 根据需要重复10-12次。
14. 问，“我解决了问题吗？”
15. 如果没有，请冲洗，起泡并重复1-15。

Answer 8

这是一个棘手的问题。 IMO，它们在您的规划和设计阶段都是并行的。它们是如此密切相关，以至于将它们组合在一起是有意义的。请记住，您的数据库设计几乎完全开发，而您的代码仍处于初期阶段（尽管您的应用程序逻辑应该几乎完全映射到您的头脑或纸上）

这个想法是你在问题的背景下设计你的解决方案。当您计划解决方案时，您将（或应该）将您的应用程序定义为一组事物和动作（名词和动词）。

例如，一个非常基本的帮助台程序有人和门票。人们需要创建票证，更新票证和关闭票证。需要持久存储的名词将包含您的数据库，名词+动作将包含在您的应用程序中。

有时你的表映射和表之间的关系将是显而易见的（IE人员创建票证，ticket.creatorID = people.personID），有时候，在你开始处理用例之前，关系并没有真正点击你的脑袋直到你开始编写你的代码（IE不同的ppl有不同的访问级别来定义他们可以做什么。一眼就看出这看起来像一个表中的简单字段，但在实践中它更好作为一个单独的表）。