Design von der Datenbank zuerst bis zur UI oder andersherum?

Ich mache beides. Normalerweise zeichne ich einen Prototyp aus, wie der Bildschirm aussehen wird, und versuche dann, daraus ein Datenmodell zu entwickeln. Anstatt direkt zu einer Datenbank zu gehen, finde ich, dass dies viel besser funktioniert, da ich mit meiner UI die Notwendigkeit von Eigenschaften (oder Feldern in einer Datenbank) sehen kann, an die ich sonst nicht gedacht hätte. Von dort entwickle ich dann das Modell und hüpfe hin und her, bis beide den Bedürfnissen der Anforderung entsprechen und dann sorge ich mich um Datenbankschemata. In der Regel wird das Modell selbst das Schema für mich definieren, so dass darauf geachtet wird.

Für den durchschnittlichen Benutzer ist die Benutzeroberfläche IS die Software. Sie kümmern sich nicht darum, wie Daten gespeichert werden, welche Plattform Sie verwenden usw. Wenn Ihre Software von Menschen genutzt wird, empfehle ich dringend, mit einer Benutzeroberfläche zu beginnen - entweder mit einem Prototyp oder mit Mockups. Zeigen Sie das den Benutzern und erhalten Sie Feedback. Erstellen Sie dann die Business-Schicht und Datenschicht.

Ich finde, dass dies hilft, Anforderungen zu sammeln. Nicht-technische Benutzer sagen Ihnen viel eher "Oh, Moment, wir brauchen ein anderes Feld auf dieser Seite" als "Wir brauchen ein anderes Attribut in diesem Tabellenschema". Sie können auch sagen "wir brauchen einen anderen Knopf hier", was normalerweise zu einer zusätzlichen Geschäftslogik führt, usw.

Dies scheint sehr situationsbedingt zu sein. Mit der Arbeit, die ich mache, beginnt die meiste Arbeit in der Datenbank, weil die Datenbanken, an denen ich arbeite, Unternehmensressourcen sind - sie werden von mehreren Benutzeroberflächen verwendet. Es wäre schädlich, die DB um die Launen einer bestimmten Benutzeroberfläche herum zu gestalten, die sich wahrscheinlich oft ändern wird.

Andererseits gibt es Situationen, in denen es sinnvoller ist, sich auf die Benutzeroberfläche zu konzentrieren und das Datenbankdesign später auszuführen - beispielsweise in einer eingebetteten mobilen DB-App.

Legen Sie Ihre Bildschirme zuerst so aus, dass Sie wissen, was Sie in der Datenbank benötigen.

Wenn Sie mit der Datenbank beginnen, beginnen Sie normalerweise mit einer Reihe von Annahmen darüber, wie die Anwendung funktioniert.

Ich tendiere dazu, in der Mitte zu beginnen und herauszufinden, was die App tun soll und wie, und dann zwischen der Benutzeroberfläche und dem Datenbankentwurf hin- und herzuschalten, da sie sich gegenseitig informieren können.

Im Allgemeinen beginne ich mit der Datenbank und baue die Benutzeroberfläche entsprechend auf. Es gibt normalerweise einige Hin-und-her, da ich möglicherweise die Datenbank ändern muss, um den Anforderungen der Benutzeroberfläche oder umgekehrt zu entsprechen.

Diese Route, angefangen mit der Datenbank zuerst, ist, wie ich in der Schule unterrichtet wurde und es blieb bei mir.

Ein Programmierer, mit dem ich gearbeitet habe, würde mit der Ausgabe beginnen. Er würde zunächst herausfinden, was zu tun ist (d. H. Welche Berichte veröffentlicht werden müssen usw.), und dann daran arbeiten, welche Daten benötigt wurden, um dorthin zu gelangen. Die Benutzeroberfläche und die Datenbank wurden zur gleichen Zeit erstellt.

In den Projekten, an denen ich arbeite, stelle ich fest, dass viele meiner Anforderungen auf der Benutzeroberfläche liegen - es ist der Teil, den der Endanwender interessiert (oder zumindest darüber nachdenkt).

Im Wesentlichen finde ich heraus, was die Funktionalität zuerst sein soll. Ich beschäftige mich nicht mit UI oder wie es aussieht oder wie es eingegeben werden soll, ich beschäftige mich mit dem, was der Benutzer tun möchte.

Ich baue dann ein Datenmodell darum herum. Manchmal ist es ein sehr einfaches Datenmodell (besonders wenn es eine einfache Anforderung wie "Film abspielen" ist), manchmal ist es sehr komplex.

Erst nachdem ich darüber entschieden habe, versuche ich, eine Benutzeroberfläche zu entwickeln, die sowohl das Modell als auch die Art und Weise widerspiegelt, wie der Benutzer erwartet, dass die Eingabe funktioniert.

Nimm das für was du willst; es funktioniert für mich ziemlich effektiv.

konzentrieren Sie sich vor allem darauf, dass das System das Problem löst, das es lösen soll.

sammeln Sie Anforderungen, um den Workflow, die Daten, die Feinheiten der Benutzerinteraktion usw. zu definieren, und bauen Sie dann von dort aus.

natürlich wirst du immer zwischendurch etwas ändern müssen, aber aus meiner Erfahrung heraus finde ich, dass Leute, die eine Philosophie oder eine andere Philosophie (dh starte immer von der db und baue gegen ui und tauche ab) viele Male haben wird mit einer Lösung enden, die nicht zu dem Problem passt.

Modelliere zuerst die Domain - das wird dir zeigen, wie du deine DB erstellst. Finden Sie Ihre Anforderungen als nächstes - Was müssen die Benutzer mit der Anwendung tun? Dadurch erfahren Sie, welche Funktionalität vorhanden sein muss. Damit können Sie Ihr DB-Schema und Ihr Softwaremodell erstellen (ob es nun OO oder funktional ist, oder was auch immer, Sie werden die notwendigen Informationen haben). DANN machen Sie eine schöne Benutzeroberfläche, die die von Ihnen erstellte Funktionalität freigibt - natürlich kann die Benutzeroberfläche auch mit der Funktionalität synchronisiert werden, aber beide sollten nach der Bestimmung der Domäne kommen. p>     

Ich habe gerade erst damit aufgehört, mein Datenmodell zu entwerfen. Ich habe mit einem Entwickler zusammengearbeitet, der mich zu Domain Driven Design geführt hat. Ich sitze jetzt durch und entwerfe zuerst mein Domain-Modell und dann mein Datenmodell. Gleichzeitig berücksichtige ich alle Herausforderungen, die die UI darstellen könnte.