blocks|key|1694833|text|如果您正在尝试使用面向对象的语言解决问题，建议您开始考虑所涉及的对象。不要担心数据库或用户界面，直到你有了一个可靠的领域模型来处理所有的用例。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1694834|一开始，您不必担心数据库或UI。如果您需要持久性并且没有数据库，则可以将对象序列化到文件系统。能够使用命令行UI驱动您的应用程序是一个很好的练习，可以确保您具有良好的MVC分离。|1694835|从对象开始。|1694836|更新：|1694837|这种方法的一个优点是，它不会影响特定数据库设计的UI，反之亦然。对象对其他两层是不可知的。您根本不需要拥有UI或关系数据库。你只是得到了正确的对象。一旦有了这些，您就可以创建您喜欢的任何UI或持久性方案，并确信域模型可以处理您被要求解决的问题。|1694838|entityMap^0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|L|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|M|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|N|8|@]|9|@]|A|$]]|$1|F|3|G|5|6|7|O|8|@]|9|@]|A|$]]|$1|H|3|I|5|6|7|P|8|@]|9|@]|A|$]]|$1|J|3|-4|5|6|7|Q|8|@]|9|@]|A|$]]]|K|$]]

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.

blocks|key|255369|text|将用户放在他应得的位置。首先设计UI。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|255370|数据库只是用户需求的结果。|255371|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|F|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|G|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|H|8|@]|9|@]|A|$]]]|E|$]]

Put the user at the place he deserves. Design UI first.

Database is only a consequence of user needs.

blocks|key|255382|text|首先是用例，既不是ui也不是数据库。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|255383|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

use cases first, neither ui nor database.

blocks|key|394188|text|你的问题很主观。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|394189|我的观点(也就是这样)是数据库和底层结构应该放在第一位。放下键盘和鼠标，在纸上编辑一些笔记，通常会有所帮助。|394190|列出目标，比如你希望你的应用程序做什么，列出你需要的功能，然后开始考虑如何构建它。|394191|这种方法适用于我在应用程序设计中的工作。|394192|entityMap^0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|J|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|K|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|L|8|@]|9|@]|A|$]]|$1|F|3|G|5|6|7|M|8|@]|9|@]|A|$]]|$1|H|3|-4|5|6|7|N|8|@]|9|@]|A|$]]]|I|$]]

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.

blocks|key|1661953|text|通常，您需要在开发的解决方案中操作一些数据。因此，你应该首先考虑这些数据是如何组织的，稳定这一层在一开始是基本的。如果你身处面向对象的世界，我同意duffymo关于首先设计业务对象的评论。将这些对象映射到DB将是您工作的一部分。然后添加业务功能并处理表示层。当然，您必须时不时地进行一些重构，但重构对业务和表示层的影响通常比对数据库的影响更大。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1661954|阅读这篇文章，这是一个很好的技巧。DDD+-+Domain+Driver+Design|offset|length|1661955|entityMap|0|LINK|mutability|MUTABLE|url|http://en.wikipedia.org/wiki/Domain-driven_design^0|0|H|Q|0|0^^$0|@$1|2|3|4|5|6|7|N|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|O|8|@]|9|@$D|P|E|Q|1|R]]|A|$]]|$1|F|3|-4|5|6|7|S|8|@]|9|@]|A|$]]]|G|$H|$5|I|J|K|A|$L|M]]]]

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.
<a href="http://en.wikipedia.org/wiki/Domain-driven_design" rel="nofollow noreferrer">DDD - Domain Driver Design</a>

blocks|key|255474|text|你会在没有地基的情况下建造一座房子吗？数据库设计不是最有趣的部分，但它是大多数业务应用程序的基础，如果你弄错了，它将成为最昂贵的修复和维护成本。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|255475|也就是说，我注意到你没有理由不能一起工作，因为它们是交织在一起的。但在你做这两件事之前，你需要了解需求和你为之编写应用程序的业务。|255476|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|F|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|G|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|H|8|@]|9|@]|A|$]]]|E|$]]

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.

blocks|key|255507|text|以上所有答案都在正确的方向上解决了您的问题。也就是说，我会完全遵循SDLC。它可以帮助您了解手头问题的解决方案的必要性。然后是需求收集，然后是设计UI+/支持UI的底层结构。这是一个过程，但最终你会从中受益。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|255508|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

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.

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 ?

When i proceed to develop a software, ui design or database design, which should be first?

翻译质量差，导致语言生硬或混乱。

没有提供实际的解决方法或示例。

解答不清晰，无法理解或解决问题。

页面排版不美观，阅读体验差。

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

我试着用一些ui模拟软件来设计ui，但我发现我很难确定设计的所有细节，因为数据库还没有设计。但是如果我首先设计软件，然后同样的问题发生了，我没有UI，我如何创建一个突出的UI？

问当我继续开发软件、ui设计或数据库设计时，哪一个应该是第一位的？
EN

回答 7

Stack Overflow用户

Stack Overflow用户

Stack Overflow用户

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问当我继续开发软件、ui设计或数据库设计时，哪一个应该是第一位的？EN

回答 7

Stack Overflow用户

Stack Overflow用户

Stack Overflow用户

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问当我继续开发软件、ui设计或数据库设计时，哪一个应该是第一位的？
EN