当我继续开发一个软件时，UI设计还是数据库设计，哪个应该放在第一位？
我尝试使用一些ui模拟软件来设计ui，但我发现我很难确定设计的所有细节，因为数据库还没有设计。
但如果我第一次设计软件，那么就会出现同样的问题，我没有UI，如何创建一个突出的UI？
I tried to design the ui with some ui mocking software, but i found it's hard for me to settle down all the detail of the design, since the database didn't design yet.
But if i first design software, then the same problem occur, I didn't have the UI, how can I create a prominent UI ?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（8）
UI优先。
从用户的角度思考，模拟一个优雅且易于使用的用户界面（和工作流程），然后再考虑您将要使用的底层数据库/数据结构需要让 UI 变得栩栩如生。
如果您因为尚未设计数据库而无法设计 UI，那么恕我直言，您就做错了。您使用过多少令人烦恼的软件，因为让数据库设计驱动 UI 设计而受到困扰？
编辑：正如其他人所指出的，您需要从用例/用户故事开始。 UI 设计和数据库设计，无论您按什么顺序进行，都应该仅在您知道您的软件要做什么以及为谁做之后进行。
编辑，作者：Bryan Oakley：
（来源：gapingvoid.com）
UI first.
Mock up an elegant and easy-to-use user interface (and workflow) thinking from the point of view of the user, and only then think about the underlying database / data structures you'll need to bring that UI to life.
If you can't design your UI because you haven't yet designed your database, you're doing it wrong IMHO. How many annoying pieces of software have you used that suffered from letting the database design drive the UI design?
Edit: As others have pointed out, you need to start with use cases / user stories. The UI design and database design, whichever order you do them, should only happen after you know what your software is trying to do, and for whom.
Edit by Bryan Oakley:
(source: gapingvoid.com)
把用户放在他应得的位置上。首先设计UI。
数据库只是用户需求的结果。
Put the user at the place he deserves. Design UI first.
Database is only a consequence of user needs.
用例优先，用户界面和数据库都不是。
use cases first, neither ui nor database.
如果您尝试使用面向对象语言解决问题，建议您开始考虑所涉及的对象。在确定一个可以解决所有用例的可靠域模型之前，不要担心数据库或 UI。
一开始您不必担心数据库或用户界面。如果您需要持久性并且没有数据库，您可以将对象序列化到文件系统。能够使用命令行 UI 驱动您的应用程序是一个很好的练习，可以确保您拥有良好的 MVC 分离。
从物体开始。
更新：
这种方法的一个优点是它不会损害特定数据库设计的 UI，反之亦然。该对象与其他两层无关。您根本不需要拥有 UI 或关系数据库。你只是把对象弄对了。一旦掌握了这些，您就可以创建您喜欢的任何 UI 或持久性方案，并确信域模型可以处理您被要求解决的问题。
If you're trying to solve a problem in an object-oriented language, it's recommended that you start thinking about the objects involved. Don't worry about the database or the UI until you've got a solid domain model nailed down that addresses all the use cases.
You don't worry about the database or the UI at first. You can serialize objects to the file system if you need persistence and don't have a database. Being able to drive your app with a command line UI is a good exercise for guaranteeing that you have a good MVC separation.
Start with the objects.
UPDATE:
The one advantage that this approach has is that it doesn't prejudice the UI with a particular database design or vice versa. The object are agnostic about the other two layers. You aren't required to have a UI or relational database at all. You're just getting the objects right. Once you have that, you can create any UI or persistence scheme you like, confident that the domain model can handle the problem you've been asked to solve.
以上所有答案都朝着正确的方向解决了您的问题。也就是说，我会彻底遵循 SDLC。它可以帮助您了解当前问题的解决方案的必要性。然后是需求收集，然后设计 UI/支持 UI 的底层结构。这是一个过程，但最终您会受益。
All the above answers address your issue in a right direction. That said, I would follow the SDLC thoroughly. It helps you understand the need for the solution for the problem at hand. Then comes the requirement gathering followed by the design either UI / underlying structure that supports the UI. It's a procedure but you would benefit in the end.
你的问题很主观。
我的观点（也正是如此）是数据库和底层结构应该放在第一位。放下键盘和鼠标并在纸上编写一些笔记通常会有所帮助。
制定目标，例如您希望应用程序执行的操作，列出您需要的功能，然后开始考虑如何构建它。
这种方法对我在应用程序设计中很有效。
Your question is very subjective.
My opinion (and it is just that) is that database and underlying structure should come first. It can often help to put down the keyboard and mouse and compile some notes on paper.
Lay out goals like what you want your application to do, list the features you require and then start thinking about how you'll build it.
This method works for me in application design.
通常您需要在开发的解决方案中操作一些数据。所以你首先应该考虑这个数据是如何组织的，稳定这一层是一开始的基础。我同意 duffymo 的评论：如果您处于 OO 世界，请首先设计业务对象。将这些对象映射到数据库将是您工作的一部分。然后添加业务功能并在表示层上工作。当然，您必须不时地进行一些重构，但通常重构对业务层和表示层的影响比对数据库的影响更大。
阅读本文，这是一个很好的技术。
DDD - 域驱动程序设计
usually you need to manipulate some data in the solutions you develop. So you should consider how this data is organised first, stabilizing this layer is fundamental at the beginning. I agree with duffymo's comment about designing the business objects first if you are in a OO world. Mapping these objects to the DB will be a part of your work. Then you add business functionality and work on the presentation layer. Of course you will have to do some refactoring from time to time, but usually the refactoring impacts the business and presentation layers more than the database.
read this, it is a good technique.
DDD - Domain Driver Design
没有地基你会盖房子吗？数据库设计并不是有趣的部分，但它是大多数业务应用程序的基础，如果出错，修复和维护成本最高。
也就是说，我注意到，没有理由不能同时处理两者，因为它们相互交织。但在执行任何操作之前，您需要了解需求以及您正在为其编写应用程序的业务。
Would you build a house without a foundation? Database design isn't the fun part but it is the foundation of most business apps and if you get it wrong it becomes the most costly to fix and the most costly to maintain.
That said, I note that there is no reason you can't work on both together as they intertwine. But before you can do either, you need to understand the requirements and the business you are writing the app for.