Sollte ich zuerst die Anwendung oder das Modell (Datenbank) entwerfen?

Question

Ich bereite mich darauf vor, ein neues Web-Projekt in meiner Freizeit zu bauen, um eine Idee, die für eine Weile um meinen Kopf herumhüpft, zu verwirklichen.

Ich bin nie runtergekommen, ob es mir besser geht, zuerst das Modell zu bauen und dann die konsumierende Anwendung oder umgekehrt.

Was sind die besten Praktiken? Was würdest du zuerst bauen und warum?

Ich stelle mir vor, dass die Anwendung im Allgemeinen das Modell fahren sollte, aber die Anwendung wie viele Websites tut wirklich nicht viel ohne das Modell.

Aus irgendeinem Grund finde ich es manchmal einfacher, in Bezug auf das Modell zu denken, da die Anwendung wirklich nur Aktionen auf dem Modell ist. Ist das eine schlechte Art, über Dinge nachzudenken?

Welche Vorteile/Nachteile hat jede Option?

Answer 1

Wenn Sie die gesamte Anwendung selbst erstellen, würde ich mit dem Benutzer beginnen. Was möchte der Benutzer? Welche Informationen benötigen sie? Das sollte das Design der Anwendung und des Modells bestimmen, nicht umgekehrt. Wenn das Modell zuerst entworfen wird, besteht die Versuchung, den Benutzer direkt darauf hinzuweisen, was selten Sinn ergibt.

Answer 2

Die meisten Web-Anwendungen tun nicht viel mehr als nur die Verarbeitung und Präsentation verschiedener Arten von Daten.

Ich würde mit genau dem beginnen: Welche Daten möchte ich verarbeiten?

Danach können Sie anfangen zu modellieren, wie diese Daten am besten in eine Datenbank passen.

Dann sollten Sie auch darüber nachdenken, wie Sie auf diese Daten zugreifen - gibt es Ihnen Hinweise zur Optimierung im Speicher?

Ich würde die Anwendung selbst entweder am Ende oder sogar parallel dazu entwerfen. Das Anwendungsdesign sollte unabhängig vom Datenbankmodell sein. Es ist nur der Code selbst, der letztendlich auf die Datenbank zugreift.

Aber Web-Anwendungen neigen auch dazu, zu wachsen. Ein evolutionäres Modell, bei dem Sie der Datenbank neue Felder oder Tabellen hinzufügen und neuen Code erstellen, ist sehr verbreitet.

Answer 3

Nun, bis zu einem gewissen Grad müssen die Anforderungen zuerst kommen. Die Datenbank ist schließlich der Diener Ihrer Anforderungen, nicht umgekehrt.

Es scheint mir, dass was Sie wirklich fragen ist: sollten Sie die Anwendung komplett vor dem Start auf der Datenbank entwerfen (und dann Code danach schreiben)?

Meine Antwort ist nein. Es ist besser hineinzuspringen und sich schnell zu bewegen.

Ich würde wahrscheinlich die App in groben Zügen entwerfen und dann einen iterativen Ansatz verwenden. Was ist eine Idee von Agile. Es gibt eine Menge da draußen zu diesem Thema.

Nun, wenn dies ein zweijähriges Projekt mit 20 Entwicklern, Stakeholdern und einem Budget wäre, wären die Dinge etwas anders ... Aber vielleicht nicht so anders, wie Sie denken! Je komplexer Sie sind, desto schwieriger wird es, einen perfekten, monolithischen Plan zu erstellen.

Some people say there is a point where it actually becomes impossible.

Answer 4

Sie wollen nicht Ihr Objektmodell durch ein Datenbank-Design eingeschränkt werden. Die Datenbank sollte eine Persistenzimplementierung Ihres Objektmodells sein, das die Regeln ist. Sie können Ihre Anwendung um Ihr Objektmodell wickeln und auch das Persistenzmodell ableiten.

Answer 5

Sie könnten damit beginnen, die Schnittstelle zwischen den Anwendungs- und Modell- und Schreibeinheitstests so zu gestalten, wie sich die Schnittstelle verhalten soll. Normalerweise nehme ich den agileren Ansatz und mache nur ein kleines Vorausdesign, bevor ich in den Code einspringe (siehe: Pragmatische Programmierer vom Gesellen zum Master Tracer Bullets Konzept).

Answer 6

Persönlich, nachdem ich die Anforderungen (formell oder nicht) kenne, entwerfe ich das Datenmodell, um die Anforderungen zu behandeln. Dann bauen Sie von dort aus mit der Business-Schicht, der Persistenz, dem Komponententest und schließlich der GUI aus.

Wenn Ihre DB das erste Mal richtig entworfen wird, sollte alles fließen.

EDIT-Bitte beachten Sie, dass ich nicht unterstelle, dass Ihre Business-Schicht oder GUI eine direkte Reflexion Ihres DB-Modells sein sollte. Manchmal wird es ähnlich sein, manchmal wird es nicht. Aber Ihr DB-Modell sollte alle Anforderungen erfüllen können.

Answer 7

Wie wäre es mit beiden?

Ein anderer Ansatz ist "Feature-basierte" Entwicklung - Erstellen Sie einen vertikalen Schnitt durch die Anwendung, gerade genug am Modell, Persistenz und Schnittstellenebenen, um eine Funktion vollständig zu erhalten. Dies könnte so einfach sein wie das Anmelden oder Bearbeiten eines einzelnen Objekts.

Dieser Ansatz bedeutet, dass:

• Sie ein kleines Stück von beiden Modellen und Anwendung zusammen vorne zu bauen bekommen;
• entdecken Sie schnell alle Gefahrenbereiche in dem Stapel von Technologien und Designs, die Sie ausgewählt haben;
• Sie haben schnell etwas, was Sie den Leuten für Kommentare zeigen können;
• Sie den Irrtum vermeiden, dass alles beim ersten Mal richtig gestaltet wird ...

Answer 8

Laut Martin Fowler, die fähigsten Entwickler als eine der „Behörden“ erkennen in diesen Fragen Sie Ihre OO Hierarchie entwerfen und dann "Zuordnen" der Objekte in Ihre Datenbank mit Hilfe von zB das Activeentwurfsmuster ...

Answer 9

FWIW, einer der am besten in Erinnerung Teile Brooks Der Mythical Man Month ist dies:

Zeigen Sie mir Ihre Flussdiagramme und Tabellen verbergen, und ich werde auch weiterhin sei verblüfft, zeig mir deine Tabellen, und ich brauche deine Flussdiagramme normalerweise nicht; Sie werden offensichtlich sein.

Answer 10

Meine Taktik ist in etwa so:

die Anforderungen Lesen und Schreiben Sie alle Substantive oder „Spieler“ im Dokument. Dies sind normalerweise 80% der Dinge, die Sie speichern oder mit denen Sie interagieren müssen.

Mit diesen Dingen auf einem Blatt Papier, lesen Sie die Anforderungen erneut und sehen Sie, ob Sie finden können, dass die Dinge, die Sie auf Papier haben, tatsächlich verwendet werden können, um die Arbeit zu erledigen.

Die, finden ihre Attribute und erstellen ein Datenmodell. Versuchen Sie, das in die Datenbank einzupassen. Baue von dort auf.

Für Web-Anwendungen funktioniert das normalerweise für mich (auch für Anwendungen mit großen Größen). Wie Sie bemerkt haben, habe ich keine Begriffe wie UML oder ERD verwendet. Dies sind nur Werkzeuge, um das Modell in Ihrem Kopf mit anderen zu kommunizieren. Powerpoint kann das auch. Es ist die Qualität des Endprodukts.

Answer 11

Zuerst ist Ihre Datenbank nicht Ihr Modell, es ist nur der Mechanismus, den Sie verwenden, um Ihr Modell zu erhalten. Ihr Modell ist eine Gruppe von Geschäftsobjekten, die den vom Unternehmen verwendeten Status und die Logik kapseln und von anderen Anwendungen verwendet werden können.

Ich habe festgestellt, dass die meisten Clients Tabellen, Spalten nicht verstehen, aber Prozess und Workflow verstehen. Daher arbeite ich mit dem Client zusammen, um die Benutzeroberfläche und den Seitenfluss für die Aufgaben nachzubilden, die in der Lösung behandelt werden müssen. Daraus erstelle ich die Geschäftsobjekte, die die erforderlichen Daten für die Benutzerschnittstelle enthalten.

Die Controller verarbeiten die Seitenlogik und den Seitenfluss. Ich modelliere ein Datenrepository, um einige Beispieldaten zu verarbeiten. Dies ermöglicht dem Client und mir, die Benutzeroberfläche zu durchlaufen und zu fließen, bis wir zufrieden sind. Normalerweise entdecken wir bessere Möglichkeiten, Dinge zu tun, und die Aktivitäten, die sie für wichtig hielten, bringen keinen Mehrwert.

Jetzt ist die Zeit, ich arbeite an der Datenbank und der Datenzugriffslogik. Warten bis zu diesem Punkt reduziert die Notwendigkeit, Datenbankschema, gespeicherte Prozeduren und DAL-Code zu überarbeiten.

Dies führt normalerweise zu weniger Code, einer robusten Anwendung und einem glücklichen Client. Die dreifache Krone.

Auch Unit Test alles. Sie werden Änderungen vornehmen und ein guter Komponententest stellt sicher, dass Sie bei der Durchführung der Änderungen keine anderen Teile Ihrer Anwendung durchbrechen.

Answer 12

Für mich hängt es vorherige Erfahrung mit der Problemdomäne ab.

Wenn ich diese Art von App schon einmal gemacht habe, nehme ich mir eher die Zeit, das Datenmodell zu klären und dann mit dem Aufbau von Code zu beginnen.

Bei einem erstmaligen Projekt bin ich eher beim Codieren, beim Auffrischen von Dummy-Daten und beim Erlernen verborgener Dimensionen der Problemdomäne. Nicht selten gibt es Datenkategorien, die schwer zu antizipieren gewesen wären. Wenn ich diese aufspüre, überarbeite ich das Datenmodell und fahre fort. Oft beginnt dieser Ansatz mit der Codierung eines Skripts, um die Datenbank zu erstellen und zu bevölkern. Auf diese Weise ändere ich bei nachfolgenden Iterationen einfach das db-build-Skript, führe es aus und bin wieder im Geschäft.

Answer 13

Dies ist die uralte Frage. Die Antwort ist, wie jede CS Antwort, dass es darauf ankommt. 90% der Anwendungen, die Sie schreiben, sind nur Formulare über Daten. In vielen dieser Anwendungen haben Sie Legacy-Anwendungen mit Daten, die Sie von dort aus portieren müssen. Daher, ob Sie es mögen oder nicht, die Daten/Datenbank ist ein einschränkender Faktor und es treibt, was auch immer Sie tun. Es ist nicht nur ein Ort, um Ihre Domain-Objekte zu speichern, es ist Ihre Domäne, auch wenn das nicht der "richtige" Weg ist, Dinge zu tun.

In den meisten Fällen habe ich mein Datenmodell zunächst so entworfen, dass die vorhandenen Daten in das relationale Modell übernommen werden.Ich mache dann grundlegende Bildschirmgestaltung. Dann baue ich meine anämischen Active-Record-Business-Objekte, um sie zu verkabeln. Dies ist bei weitem nicht der beste Weg, um Software zu entwickeln, aber in den meisten Fällen ist es die Art und Weise, wie Dinge erledigt werden oder getan werden. In diesen Fällen sind Ihre Geschäftsobjekte wirklich nur Container für Daten mit Geschäftslogik um sie herum, um sie mit den Bildschirmen zu verbinden und die Datenintegrität und Bildschirmsicherheit zu gewährleisten. Diese saugt, aber es ist was es ist.

Wenn Bildschirm-Interaktionen das Wichtigste sind, dann vielleicht zuerst den Bildschirm entwerfen und dann haben Sie andere Objekte davon abhängen, wird Ihre beste Wette sein.

Wenn Sie das Glück haben, ein Greenfield-Projekt zu haben, bei dem die Domäne integraler Bestandteil der Anwendung ist und die Datenbank lediglich ein Persistenzmechanismus für Ihre Domänenobjekte ist, würde ich die Domänenobjekte zunächst mit dem Domain Driven Design in einem TDD entwickeln Manor und entwickeln Sie die Bildschirme und die Datenbank um die Domain-Objekte. Ich würde Liebe, um so häufiger zu kodieren, aber Sie erhalten nicht immer die Gelegenheit an den meisten Orten.

Hinweis: Stack Overflow ist in einer Datenbank als Modell Weg konzipiert, so kann es nicht , dass böse.

Answer 14

Sie wissen, ich denke, ich muss denen widersprechen, die blind das Design der GUI vor dem zugrunde liegenden Datenmodell setzen. In einer realen Geschäftsumgebung dreht sich der Geschäftsbetrieb nicht nur um den Arbeitsablauf - eine große Komponente des Geschäfts, die sich auf Datenanalyse und Berichterstellung konzentriert. Wie können Sie Entscheidungen basierend auf Daten treffen, die Sie nicht verstehen können? Wenn Sie sich in 90% der Fälle mit einem Kunden hinsetzen, verstehen sie auch nicht, was ihre Anwendung zu tun hat, wie sie angelegt werden muss und die Hälfte der Zeit, sie verstehen nicht einmal was Funktionalität erfordert.

Wie analysieren Sie Ihre Daten, wenn Ihr gesamtes Datenmodell nur eine Persistenz von Bildschirmdaten ist? Wie berichten Sie darüber? Wenn Sie sich mit einem Datenbank-Guru zusammensetzen und ihm mitteilen, dass Sie einen Bericht aus einem Datenmodell erstellen möchten, das im Grunde Ihren ViewState darstellt, würden sie aufhören und Sie auffordern, es selbst zu tun - zumindest, wenn mir jemand sagt, dass ich einen Bericht erstellen muss Basierend auf dieser Art von Modell würde ich aufhören und ihnen sagen, dass sie jemand anderen dazu bringen sollen.

Die GUI, die oben auf dem Datenmodell sitzt, ist nebensächlich und ermöglicht Mitarbeitern, mit den Daten auf die einfachste und effizienteste Weise zu interagieren. Bedenken Sie, dass Softwarebenutzer keine Programmierer sind, sie denken nicht so wie Programmierer oder Datenbankarchitekten, und sie arbeiten nicht so, wie wir arbeiten; noch wollen sie. Sie möchten Daten einfach und auf die logischste Weise gemäß ihrem täglichen Arbeitsablauf eingeben können. Sie wollen denken können, wie viel kann ich heute machen, damit ich, wenn ich nach Hause gehe, keine Arbeit mit mir nehmen muss, sie wollen in den Urlaub fahren, ohne sich Sorgen zu machen, ob der neue Mann in der Lage sein wird, zu bleiben mit dem Fluss oder wenn sie in der Lage sein werden, die Software zu verstehen.

Geschäftsinhaber möchten in der Lage sein, die Daten auf die einfachste und effizienteste Art und Weise zu erhalten. Sie möchten Berichte, die in kürzester Zeit geschrieben werden, und möchten, dass die Daten logisch, effizient und repräsentativ für jedes aktuelle Modell dargestellt werden Bericht. Sie kümmern sich wenig um den Workflow, sie brauchen nicht zu wissen, wie viele Abteilungen diese Daten durchflossen haben, woher sie kamen, wie sie dorthin gelangt sind, wo sie jetzt sind. Sie wollen wissen, was das Datenstück ist, was es darstellt und was es für das Geschäft als Ganzes bedeutet.

Für einen Geschäftsinhaber sind die Daten viel wichtiger als das Stück Software. Für den Endbenutzer, der unter zehnmal mehr Zeit zehn Mal mehr Druck ausüben muss, muss die Software ihnen die Möglichkeit geben, in kürzester Zeit so viele Daten wie möglich in die Datenbank zu bringen.

Also wie entscheiden Sie, welches Design zuerst, die GUI oder das Datenmodell? Wie viel Geld wird längerfristig eingespart? Hat das Unternehmen 500 Benutzer, die Daten in diese Software eingeben, und tun sie dies auf die effizienteste Art und Weise? Verfügt das Unternehmen über 500 Berichtsautoren und können sie schnell und effizient auf die Daten zugreifen? Wie lang ist ein Stück Schnur?

Gestalten Sie Ihr Datenmodell für die Datenanalysten - machen Sie es so sauber und effizient wie möglich, um die Daten in einem umfassenden Format zu erhalten.

Entwerfen Sie Ihre GUI für die Endbenutzer und machen Sie es so sauber, einfach und effizient, wie es für diese Benutzer sein kann, um so schnell und einfach wie möglich Daten in Ihre Datenbank zu bekommen, ohne ein Raketenwissenschaftler zu sein. Häufig sind Endanwender im Vergleich zu denen, die die Software schreiben und die Daten extrahieren, kaum Computerkenntnisse.

Denken Sie von Anfang an immer daran, wie Sie die beiden miteinander verbinden, denn wenn Sie dies nicht tun, haben Sie zwei Enden und keine Möglichkeit, eine Mitte bereitzustellen, auf die Ihr Projekt fallen wird Stücke ...

Mehr Geld wird verschwendet, indem man Daten in ein System steckt und die Daten herausholt, als die Software zu schreiben, die die Verdrahtung zwischen den beiden Enden macht. Ein Team von Entwicklern kostet nicht annähernd das, was ein Unternehmen kostet, dessen Benutzer ungenaue Daten ineffizient und schlechte Qualitätsberichte eingeben, weil die Datenanalysten nicht effizient auf diese ungenauen Daten zugreifen können und eine Woche damit verbringen, einen Bericht zu schreiben, der nicht realistisch ist dauert mehr als eine Stunde oder zwei und wenn es geschrieben wird, ist sowieso keine Hilfe.

Answer 15

Es ist eine, die in beide Richtungen funktioniert, aber persönlich lehne ich mehr und mehr auf die Gestaltung von der Benutzeroberfläche zurück.

Der Hauptgrund liegt in der Möglichkeit, unterstützende automatisierte Tests zu erstellen.

Eine der Stärken des automatisierten Testens ist die Flexibilität, Ihren Code zu ändern und zu ändern, während Sie fortfahren. Die Benutzeroberfläche ist jedoch normalerweise am schwierigsten zu ändern, und die, die oft die meiste Arbeit erfordert, um richtig zu werden.

Aus diesem Grund, ich befürworte das Entwerfen der Benutzeroberfläche, holen Sie es so nah wie möglich an die fertige Version, dann rückwärts gehen, erstellen Sie Ihre Mitte und Back-End zur Unterstützung der Operationen in dieser GUI ausgeführt.

Mit einer relativ stabilen (und schwer zu testenden) Benutzeroberfläche können Sie die anderen Ebenen mit viel mehr Flexibilität modellieren, sobald Sie eine gute Testabdeckung für sie haben.

Wenn Sie aus der Datenbank nach oben entwickeln, erhalten Sie eine stabile, einfach zu testende Datenbank und eine Menge Unordnung, um die GUI genau zu dem zu bringen, was Sie mit der DB gemacht haben - was endet Es dauert viel länger, da Sie am meisten Änderungen an dem System vornehmen, das am schwierigsten zu testen ist und die geringste Testabdeckung aufweist.

Plus die Tatsache, dass DB getriebene entworfene Anwendungen am Ende haben keine Persönlichkeit und sind schwierig zu bedienen. Sie sehen für jeden Bildschirm wie das gleiche MS Access-Formular aus, außer mit verschiedenen Feldern.

Answer 16

Aus Erfahrung kann das Entwerfen der Datenbank zuerst (basierend auf Anforderungen) dazu führen, dass die Dinge reibungslos verlaufen.

Dies gilt insbesondere dann, wenn sich Ihre Daten nicht nur auf Daten beziehen, die auf der Benutzeroberfläche eingegeben wurden, sondern auch bereits vorhandene Daten für das Projekt enthalten oder importiert werden können.

Bei einem mittelgroßen Projekt kann ich mehr als 100 Iterationen der Datenbank mit einem ERD-Diagramm-Tool wie Erwin oder Power SQL durchlaufen. Klicken Sie dann auf den Forward-Engineer-Button, um die DDL zu erhalten.

Die Domänenobjekte ähneln in der Regel weitgehend Ihren Haupttabellen, enthalten jedoch häufig Auflistungen, in denen die Datenbank Nachschlagetabellen usw. enthält. Auch Ihre Domänenobjekte können aus organisatorischen Gründen andere Objekte enthalten.

Dann verdrahten Sie eine DAL entweder handgerollt oder ORM Ihrer Wahl.

Die Sache ist, keines der Tools, die entwickelt wurden, um diesen Prozess zu automatisieren, scheint es zu 100% zu tun. In einer Code-Utopie könnte man einfach das DB-Modell erstellen und das perfekte Domänenmodell erstellen oder umgekehrt, und dann mit wenigen Klicks ein perfektes ORM erhalten. In Wirklichkeit ist dies viel schwieriger als es klingt, und subtile Probleme wie Leistung und Flexibilität können auftreten.