我尝试使用一些 ui 模拟软件来设计 ui,但我发现我很难确定设计的所有细节,因为数据库还没有设计。
但是如果我第一次设计软件,就会出现同样的问题,我没有 UI,如何创建一个突出的 UI?
首先是用户界面。
从用户的角度模拟一个优雅且易于使用的用户界面(和工作流程),然后才考虑使该 UI 栩栩如生所需的底层数据库/数据结构。
如果您因为尚未设计数据库而无法设计 UI,那么恕我直言,您做错了。你用过多少恼人的软件让数据库设计驱动 UI 设计?
编辑:正如其他人指出的那样,您需要从用例/用户故事开始。UI 设计和数据库设计,无论你按照什么顺序进行,都应该在你知道你的软件试图做什么以及为谁做之后发生。
布莱恩·奥克利编辑:
(来源:gapingvoid.com)
如果您尝试使用面向对象的语言解决问题,建议您开始考虑所涉及的对象。不要担心数据库或 UI,直到您确定了一个可以解决所有用例的可靠领域模型。
一开始您不必担心数据库或 UI。如果您需要持久性并且没有数据库,您可以将对象序列化到文件系统。能够使用命令行 UI 驱动您的应用程序是一个很好的练习,可确保您拥有良好的 MVC 分离。
从对象开始。
更新:
这种方法的一个优点是它不会影响具有特定数据库设计的 UI,反之亦然。该对象与其他两层无关。您根本不需要拥有 UI 或关系数据库。你只是得到了正确的对象。一旦你有了它,你就可以创建任何你喜欢的 UI 或持久性方案,确信域模型可以处理你被要求解决的问题。
将用户放在他应得的位置。首先设计用户界面。
数据库只是用户需求的结果。
首先是用例,既不是 ui 也不是数据库。
你的问题很主观。
我的观点(仅此而已)是数据库和底层结构应该放在第一位。它通常可以帮助放下键盘和鼠标并在纸上编写一些笔记。
列出您希望应用程序执行的目标,列出您需要的功能,然后开始考虑如何构建它。
这种方法在应用程序设计中适用于我。
通常你需要在你开发的解决方案中操作一些数据。所以你应该首先考虑如何组织这些数据,稳定这一层是一开始的基础。如果您处于 OO 世界,我同意 duffymo 关于首先设计业务对象的评论。将这些对象映射到数据库将是您工作的一部分。然后添加业务功能并在表示层上工作。当然,您必须不时进行一些重构,但通常重构对业务和表示层的影响比对数据库的影响更大。
读这个,这是一个很好的技术。 DDD - 域驱动程序设计
你会建造没有地基的房子吗?数据库设计不是最有趣的部分,但它是大多数商业应用程序的基础,如果你弄错了,它就会成为最昂贵的修复和最昂贵的维护。
也就是说,我注意到你没有理由不能一起工作,因为它们相互交织。但在你做任何一个之前,你需要了解需求和你正在编写应用程序的业务。
以上所有答案都朝着正确的方向解决了您的问题。也就是说,我会彻底遵循 SDLC。它可以帮助您了解解决手头问题的必要性。然后是需求收集,然后是设计 UI / 支持 UI 的底层结构。这是一个程序,但你最终会受益。