先从数据库设计到用户界面还是从其他方面设计?

我两个都做。我通常会画出一个屏幕将是什么样子的原型,然后尝试从中开发一个数据模型。与直接访问数据库不同,我发现这比使用我的UI更有效,我可以看到对属性(或数据库中的字段)的需求,否则我不会想到。从那里开始,我开发模型,来回地返回,直到两者都适合需求的需要,然后我担心数据库模式。通常,尽管模型本身会为我定义模式,所以这是需要考虑的。

对于普通用户,用户界面 是 软件。他们不关心数据是如何存储的,你使用什么平台等等。所以如果你的软件将被人们使用,我强烈建议从一个用户界面开始——原型或者模型。向用户展示并获得反馈。然后构建业务层和数据层。

我发现这有助于收集需求。非技术用户更可能告诉您“哦,等等,我们需要这个页面上的另一个字段”而不是“我们需要这个表模式中的另一个属性”。他们也可能会说“我们这里需要另一个按钮”,这通常翻译成一些附加的业务逻辑,等等。

这似乎是非常情景化的。对于我所做的工作,大多数工作都是从数据库开始的,因为我所处理的数据库是企业资源——它们由多个UI使用。让DB围绕可能经常改变的特定UI的变幻莫测进行设计是有害的。

另一方面,在某些情况下,将注意力集中在用户界面上可能会更有益,并让数据库设计稍后到来——例如,在嵌入式DB移动应用程序中可能会更有益。

首先设计屏幕,这样您就知道数据库中需要什么。

如果从数据库开始,那么通常是从一组关于应用程序将如何工作的假设开始的。

我倾向于从中间开始,计算出应用程序将做什么以及如何做,然后在用户界面和数据库设计之间来回切换,因为它们可以互相通知。

通常,我首先从数据库开始,然后构建适合它的UI。通常会有一些来回,因为我可能需要更改数据库以适应UI的需求,或者反之亦然。

这条路线,首先从数据库开始,是我在学校的教学方式,它一直困扰着我。

一个与我一起工作的程序员将从输出开始。他首先要弄清楚需要做什么(例如,哪些报告需要出来等等),然后再研究需要什么数据才能到达那里。用户界面和数据库是同时构建的。

在我所从事的项目中,我发现UI是我很多需求的来源——它是最终用户关心的部分(或者至少是思考的部分)。

基本上,我发现 功能 应该是第一个。我不处理用户界面,也不处理它的外观,也不处理它应该如何输入,而是处理用户想要做什么。

然后我围绕这个构建一个数据模型。有时它是一个非常简单的数据模型(特别是如果它是一个简单的需求,比如“播放一部电影”),有时它是非常复杂的。

只有在确定了这一点之后,我才会尝试设计一个既反映模型又反映用户期望输入如何工作的UI。

照你的意愿去做,这对我来说相当有效。

最重要的是,首先要集中精力确保系统能够解决它要解决的问题。

收集需求以定义工作流、数据、用户交互复杂性等,然后从中构建。

当然,你总是需要在这里或那里做些调整,但是从我的实践中,我发现那些赞同一种或另一种哲学的人(即总是从数据库开始,建立起来,而不是从用户界面开始,然后向下俯冲)很多次都会最终得到一个不适合问题的解决方案。

首先对域建模-这将告诉您如何构建数据库。接下来查找您的需求-用户需要如何处理该应用程序?这将告诉您需要哪些功能。有了它,您就可以创建您的DB模式和软件模型(无论是OO模式,还是功能模式,或者其他什么模式,您都将获得必要的信息)。然后创建一个漂亮的用户界面,公开您构建的功能——当然,用户界面构建 可以 也要与功能同步完成,但这两者都应该在确定域的外观之后进行。

我最近刚停止设计我的数据模型。我和一个开发人员合作,让我转向了领域驱动的设计。我现在先坐下来设计我的领域模型,然后设计我的数据模型。同时,我考虑了用户界面可能存在的任何挑战。