我正准备在业余时间开始建立一个新的网络项目，以实现一段时间在我脑海中蹦蹦跳跳的想法。
我从来没有意识到我是否更好地首先建立模型，然后是消费应用程序或其他方式。
最佳做法是什么？你会先建造什么？为什么？
我认为通常应用程序通常应该驱动模型，但是如果没有该模型，像许多网站这样的应用程序实际上并没有那么多。
出于某种原因，我发现有时更容易根据模型进行思考，因为应用程序实际上只是对模型的操作。这是一种思考问题的糟糕方式吗？
每个选项有哪些优点/缺点？
答案 0 :(得分：26)
当您自己构建整个应用程序时，我会从用户开始。用户想要什么？他们需要什么信息？这应该推动应用程序和模型的设计，而不是相反。当模型首先被设计时，有一种诱惑是直接将用户暴露给它，这很少有意义。
答案 1 :(得分：19)
就个人而言，在我了解了要求（正式与否）后，我设计了数据模型来处理要求。然后从那里开始构建，包括业务层，持久性，单元测试，最后是GUI。
如果您的数据库第一次设计正确，一切都应该流动。
编辑 - 请注意，我并不是说您的业务层或GUI应该直接反映您的数据库模型。有时它会相似，有时却不会。但是你的数据库模型应该能够满足所有要求。
答案 2 :(得分：11)
首先，您的数据库不是您的模型，它只是您用来保存模型的机制。您的模型是一组业务对象，它封装了业务使用的状态和逻辑，可以被其他应用程序使用。
我发现大多数客户端不了解表，列，但了解流程和工作流程。因此，我与客户一起模拟用户界面和解决方案中需要解决的任务的页面流。由此，我创建了业务对象来保存UI所需的数据。
控制器处理页面逻辑和页面流。我模拟了一个数据存储库来处理一些示例数据。这允许客户端和我迭代UI并流动直到我们满意为止。通常，我们会发现更好的做事方式，以及他们认为重要的一些活动，没有任何价值。
现在是我处理数据库和数据访问逻辑的时候了。等到这一点为止，减少了重新编写数据库模式，存储过程和DAL代码的需要。
这通常会导致更少的代码，强大的应用程序和愉快的客户端。三冠王。
另外，单元测试一切。您将进行更改，并且一个好的单元测试集确保您在进行更改时不会破坏应用程序的其他部分。
答案 3 :(得分：9)
你知道，我认为我必须不同意那些盲目地将GUI设计置于基础数据模型之前的人。在真实的商业环境中，运营业务不仅仅与工作流程有关 - 工作流程是围绕数据分析和报告的重要业务组成部分。毕竟，您如何根据您无法获得或理解的数据做出决策？最重要的是，当你与客户坐下来时，90％的时间，他们不明白他们的应用程序需要做什么，需要如何布局和一半时间，他们甚至不明白什么它需要的功能。
如果整个数据模型只是屏幕数据的持久性，那么如何分析数据？你是如何报道的？如果你坐下来与一个数据库大师并告诉他们你想要一个基本上代表你的ViewState的数据模型构建的报告，他们会退出并告诉你自己做 - 至少，如果有人告诉我我必须建立一个报告基于那种类型的模型，我会放弃并告诉他们让其他人去做。
位于数据模型之上的GUI是偶然的，允许员工以最简单，最有效的方式与数据交互。请记住，软件用户不是程序员，他们不像程序员或数据库架构师那样思考，他们不按照我们的工作方式工作;他们也不想。他们希望能够根据日常工作流程以最合理的方式轻松输入数据。他们希望能够思考，今天能完成多少工作，这样当我回家时，我不需要和我一起工作，他们想去度假而不用担心新人是否能够保持随着流程或他们将能够理解该软件。
企业所有者希望能够以最简单，最有效的方式获取数据，他们希望立刻发布报告，并且他们希望数据以逻辑，有效和代表性的方式表示他们为当前报告选择的任何模型。他们对工作流程几乎不关心，他们不需要知道这些数据流经多少个部门，它来自哪里，如何到达现在的位置。他们想知道这些数据是什么，它代表什么以及它对整个企业意味着什么。
对于企业主而言，数据远比软件重要。对于那些在十倍的时间内压力要做十倍以上的最终用户，软件需要为他们提供在最短的时间内尽可能多地将数据输入数据库的方法。
那么您如何决定首先设计哪个，GUI或数据模型？从长远来看，将节省多少钱？公司是否有500名用户在这个软件中输入数据，他们是否以最有效的方式进行操作？该公司是否有500名报告编写者，他们能否快速有效地获取数据？一根绳子有多长？
为数据分析师设计数据模型 - 使其尽可能简洁，高效，以全面的格式输出数据。
为最终用户设计GUI并使其干净，简单和高效，因为这些用户可以尽可能快地和尽可能简单地将数据输入数据库，而无需成为火箭科学家。与编写软件和提取数据的人相比，最终用户通常几乎没有计算机知识。
从一开始，要始终牢记你要如何将两者连接在一起，因为如果你不这样做，你最终会有两端，没有办法提供中间，你的项目将会崩溃...
浪费更多资金将数据放入系统并获取数据，而不是编写在两端之间进行连接的软件。由于数据分析师无法有效地获取不准确的数据并花费一周的时间编写一份实际上不应该生成的报告，因此开发人员团队的成本几乎不会低于用户输入不准确数据和低质量报告的公司的成本。花了一两个多小时，无论如何都写不出来。
答案 4 :(得分：4)
两者怎么样？
另一种方法是“基于特征的”开发 - 通过应用程序构建一个垂直切片，在模型，持久性和接口级别上足以使功能完全正常工作。这可能就像登录或编辑单个对象一样简单。
这种方法意味着：
答案 5 :(得分：4)
告诉我你的流程图并隐藏你的桌子，我将继续神秘化，向我展示你的桌子，我通常不需要你的流程图;他们会很明显。
答案 6 :(得分：3)
大多数网络应用程序除了处理和呈现不同类型的数据外，所做的工作不多。
我将从那开始：我想要处理哪些数据？
之后，您可以开始建模这些数据最适合数据库的方式。
那么您还应该考虑如何访问这些数据 - 它是否为您提供了存储优化的任何提示？
我会在最后设计应用程序，或者甚至与它平行。应用程序设计应独立于数据库模型。它只是代码本身，最终将访问数据库。
但是，Web应用程序也趋于增长。因此，在数据库中添加新字段或表并在其周围构建新代码的进化模型非常常见。
答案 7 :(得分：2)
您不希望对象模型受数据库设计的约束。数据库应该是对象模型的持久性实现，它是一个规则的实现。您可以围绕对象模型包装应用程序，还可以派生持久性模型。
答案 8 :(得分：2)
您可以从设计应用程序和模型之间的接口开始，并编写单元测试，了解接口的行为方式。在进入代码之前，我通常采用更敏捷的方法，只做一点前期设计（参见：实用程序员从Journeyman到Master Tracer Bullets概念）。
答案 9 :(得分：2)
根据Martin Fowler的说法，大多数技术熟练的开发人员都认为这些问题中的“权威”之一是您首先设计您的OO层次结构，然后使用例如“对象”将对象“映射”到您的数据库中。 ActiveRecord设计模式......
答案 10 :(得分：1)
嗯，在某种程度上，要求必须首先出现。毕竟数据库是你需求的仆人，而不是相反。
在我看来，你真正要问的是：你应该在开始使用数据库之前完全设计应用程序然后再编写代码吗？
我的回答是否定的。最好跳进去快速行动。
我可能会广泛设计应用程序，然后使用迭代方法。这是来自Agile的想法。关于这个问题有很多。
现在，如果这是一个为期两年的项目，有20位开发人员，利益相关者和预算，事情会有所不同......但也许并不像你想象的那样不同！您处理的复杂性越高，就越难以预先创建完美的整体计划。
Some people say there is a point where it actually becomes impossible.
答案 11 :(得分：1)
这是一种有效的方式，但我个人倾向于越来越多地从UI设计。
主要原因归结为能够创建支持自动化测试。
自动化测试的优势之一是可以灵活地重构和更改代码。然而，UI通常是最难改变的，并且通常需要最多的工作才能做到正确。
因此，我主张设计UI，尽可能接近完成版本，然后向后移动创建中间和后端以支持在该GUI中执行的操作。
使用相对稳定（且难以测试）的用户界面，一旦您获得了良好的测试覆盖率，您就可以更灵活地塑造其他层。
如果你从数据库中进行设计，那么你最终会得到一个稳定，易于测试的数据库，并且很容易让GUI恰到好处地匹配你对数据库的所作所为 - 最终需要花费更长的时间，因为您对系统级别进行了最大程度的更改，这是最难测试且测试覆盖率最低的。
此外，数据库驱动设计的应用程序最终没有个性且难以使用。除了不同的字段外，它们看起来与每个屏幕的MS Access窗体相同。
答案 12 :(得分：1)
根据经验，首先设计数据库（根据需求）可以使事情顺利进行。
如果您的数据不仅与UI中输入的数据相关，而且可能包含与项目相关或导入的预先存在的数据，则尤其如此。
在一个中型项目中，我可以使用Erwin或Power SQL等ERD图表工具进行100多次迭代。然后，单击forward-engineer按钮以获取DDL。
域对象通常看起来很像主表，但是它们通常具有DB具有查找表等的集合。此外，您的域对象可能还有其他对象用于组织目的等。< / p>
然后用您自己选择的手工卷制或ORM连接DAL。
事实上，设计用于自动化此过程的工具似乎都没有100％完成。在代码乌托邦中，我想你可以创建数据库模型并创建完美的域模型，反之亦然，而不是只需点击几下就可以获得完美的ORM。实际上，这比听起来要难得多，并且会出现像性能和灵活性这样的细微问题。
答案 13 :(得分：0)
我的策略大致如下：
阅读要求，并记下文档中的所有名词或“玩家”。这些通常是您需要存储或与之交互的80％。
将这些东西放在一张纸上，再次阅读要求，看看你是否能够发现纸上的东西实际上可以用来完成工作。
，找到他们的属性并制作数据模型。尝试将其纳入数据库。从那里建立。
对于Web应用程序，这通常适用于我（即使对于可用的大小应用程序）。正如您所注意到的，我没有使用像UML或ERD这样的术语。这些只是用于与其他人沟通模型的工具。 Powerpoint也可以做到这一点。这是最终产品的质量。
答案 14 :(得分：0)
对我而言，这取决于以前在问题领域的经验。
如果我以前做过这种应用程序，我更有可能先花时间澄清数据模型，然后开始构建代码。
在第一次项目中，我更有可能只是跳入编码，根据需要掀起虚拟数据，并在我去的时候了解问题域的隐藏维度。很少有数据类别难以预料。当我发现这些时，我会修改数据模型并继续。通常，这种方法始于编写脚本以构建数据库并填充它。这样，在后续迭代中，我只需修改db-build脚本，运行它，然后我又回来了。
答案 15 :(得分：0)
这是一个古老的问题。答案，就像每个CS答案一样，它取决于它。您编写的应用程序中有90％只是表单而不是数据。在许多这些应用程序中，您将拥有遗留应用程序，其中包含您必须从那里移植的数据。因此，无论您是否喜欢，数据/数据库都是一个限制因素，它可以驱动您所做的任何事情。它不是只是存储域对象的地方，它是您的域名，即使这不是“正确”的做事方式。
在大多数情况下，我首先以一种获取现有数据并将其组织到关系模型中的方式设计我的数据模型。然后我做基本的屏幕设计。然后我构建我的贫血Active Record类型业务对象来连接它们。这绝不是设计软件的最佳方式，但在大多数情况下，这是事情将要完成或已经完成的方式。在这些情况下，您的业务对象实际上只是具有业务逻辑的数据的容器，可以将它们连接到屏幕并确保数据完整性和屏幕安全性。这个很糟糕，但它就是它。
如果屏幕互动是最重要的事情，那么可能首先设计屏幕，然后让你依赖其他对象，这将是你最好的选择。
如果你有幸拥有一个Greenfield项目，其中域是应用程序中不可或缺的，而数据库只是域对象的持久性机制，那么我将首先使用TDD庄园中的域驱动设计开发域对象并围绕域对象开发屏幕和数据库。我会喜欢更频繁地编码这样的代码，但是你并不总能在大多数地方获得机会。
注意：Stack Overflow是作为Model方式在数据库中设计的，所以它不能 邪恶。