从GUI开始构建应用程序是否有用？

应用程序设计和开发的趋势似乎始于“胆量”：领域，然后是数据访问，然后是基础结构等。GUI似乎通常会在此过程的后期出现。我想知道首先构建GUI是否有用...

我的基本原理是，通过至少构建一个原型GUI，您可以更好地了解幕后需要做什么，因此可以更好地开始在域和支持代码上进行工作。

我可以看到这种做法的问题在于，如果尚未编写支持代码，那么GUI层实际上就不会做很多事情。也许构建模拟对象或一次性类（有点像在单元测试中所做的那样）将提供足够的基础来最初构建GUI。

对于实际项目，这可能是可行的想法吗？也许我们可以将GDD（GUI驱动开发）添加到首字母缩写稳定...

构建快速的GUI原型是一个好主意，我听说它已在许多项目中使用。早期反馈确实有价值。但是，它有危险：

• （对于经理/用户）非常诱人的是进一步使用原型代码并在其上构建最终应用程序，这可能会带来非常不好的长期后果（这实际上发生在我从事的一个项目中，并且导致一种不存在的架构的“有效”产品，给我们带来了很多维护麻烦）
• 对于普通用户，GUI是应用程序。因此，一旦他们看到一个漂亮的GUI，他们就会倾向于相信大部分实际工作都已完成，因此拖着这么长的“少量剩余工作”可能会很沮丧：-/

减轻这些风险需要积极讨论并可能需要对用户和/或经理进行培训。

我看到的问题是目标似乎完全落后了。

“我的理由是，通过至少构建一个原型GUI，您可以更好地了解幕后需要发生的事情，因此可以更好地开始开发域和支持代码。”

在我看来，这是查看业务层的错误方法，也是找到不良的，不可扩展的设计的绝佳方法。经过精心设计以完全表达数据的数据层可以在任何UI中使用。专为满足特定UI需求而设计的数据层可能无法适应任何其他内容，甚至不能对该UI进行次要功能添加。

使用您所谈论的方式进行系统设计的经验使我得出结论，大多数使用这种方法的设计最终都是短暂的和/或过于复杂的。它们还倾向于在UI和数据层之间创建永远不应该存在的耦合。

必须鼓励数据层和UI层的独立性。这就是从长远来看，构建数据层以仅表示整个数据而不是针对特定UI的原因。

构建原型可以很好地满足需求收集和协议要求，但随后应将其丢弃。实际上，不要在实际产品中使用原型代码中的任何内容。

我认为@Péter建议构建GUI原型是一个好主意，这是正确的。我想补充一下以落后的方式提供用户体验的潜在陷阱，即首先关注本体，体系结构和基础架构，最后关注即时用户体验：

• 您被推到开发时间轴的尽头的用户会使您对数据和应用程序使用方式的估计无效。
• 您过早开发的精心设计证明了自己是自发的诡计，最终很少或根本没有用。
• 您的应用程序可能会处于这种状态，即交付不良的用户体验已成为常态。

您进行了胆量检查，然后用户得到了您的假设得出的结论，同时您应关注用户的需求并相应地构建胆量。人们之所以选择相反的方式，仅仅是因为与应用程序的行为自然发生的用户交互的演示文稿是系统中最复杂的部分，从未被充分探索，或者人们感到非常乐于与自己建立事物有关，从而避免了不得不思考为什么要构建/为什么/为谁而思考。搭建一个结构合理的巨大结构是儿童游戏，要使其满足所有人的功能（和审美）需求是最困难的部分。

对于每个craptastic经验，古怪流，并列不良信息，缺乏明显的功能，事情是完全错误的，只要你求问“只是其中的天才想出了实例即是忽视，否定或？”，谎言的东西透露用户是开发工作的最前沿。

通常，应在查看之前开发模型。一旦有了应用程序的逻辑基础，就可以构建该模型的一个或多个视图（例如，可以在表或图形中显示数据）。通常，该模型比GUI更重要。对于通常以标准方式完成GUI的企业开发尤其如此。

但是，有时GUI确实是应用程序中最重要的部分。有时，您想以新颖和特定的方式查看数据-然后从那里获取数据，然后开发模型。例如，CashCurve是这样的应用程序，其中的关键点在GUI中，而数据模型本身就是标准的无聊的东西，任何人都可以在几分钟内进行建模。（免责声明：我不隶属于CashCurve，只是一个非常满意的用户。）

这也与设计Web服务或其他API有关-仅在这里被称为“ 合同优先 ”设计。

因此，对于所有内容，首先设计什么没有规则。有时是模型，有时是GUI。根据经验，我会“首先设计最重要的部分”。

首先设计GUI时需要注意一些注意事项，例如，当仅存在GUI原型时，用户可能会难以理解应用程序还远远不够完整，但是其他答案已经很好地涵盖了这一点，因此我将不赘述。

我认为这是一种进行应用程序设计的极好方法，尤其是在敏捷开发环境中。我从事的大多数成功项目都是从一个原型开始的，该原型最终成为了现实。

您必须了解GUI是进入系统（例如数据库，文件系统等）的窗口。在项目需求像一堆烂泥一样含糊不清的情况下，您不会希望从后端开始就获得正确的解决方案。几乎总是有一个好主意的后端开发人员开发了大量与用户交互无关的API。

通过启动GUI，客户可以更好地了解自己的需求。随着这一阶段的进展，GUI的开发（使用模拟和存根）催生了域模型。然后，可以将该域模型转移到后端，后端开发人员可以开始开发持久性和事务逻辑。

还有为什么要扔掉原型呢？我们不处理用火柴棍建造的体育场。只是把该死的东西重构成好东西。

如果看着GUI的人知道这只是一个外壳，而按钮和进程实际上不起作用，则对我来说听起来并不坏（抛出新的NotImplementedException（）;;））。

如果您坚持使用MVC样式的体系结构，那么我不会预见任何将来的维护或构造问题，因为“视图”根本没有定义任何此类问题。以后，“控制器”和“模型”可以随您需要可伸缩性/设计需求等的任何基础结构一起使用。

在管理方面，将它们绘制成一个大的饼图，分为三个部分，分别标记为“ M”，“ V”和“ C”。给V大约20％，并说明其余的部分是“ TBC”;）。

在任何大小合理的系统中，幕后需要发生的事情与GUI的外观大致相关。GUI仅会给您一些要求。通常，许多组件没有GUI。

开发系统后，可能需要其他接口（包括新的GUI）。理解和实施业务需求对于成功实现至关重要。

设计GUI以及其他输入和输出机制可以提供帮助的地方是验证模型。永远不需要输出的属性。（也许有理由保留它们，但是它们很可能是审计或监管机构的要求。）

正如其他人提到的那样，一旦您拥有了可用的GUI，许多客户就会认为您已经完成了。但是，您可能没有背后的基础架构。纸制原型可能是验证GUI的布局和内容的不错选择。

不要忽视，开发后可能需要调整界面。我听说有一个关于五步结帐流程的结帐界面替换失败的报告。简单得多的界面并没有给用户适当的安全感，并且完成率低得多。听听颠簸：行销中的神奇成分。