Ja (true), Nein(false) und Beides (both) - 3 Werte - wie am Besten umsetzen?

[Rolf B]

Hallo Der,

Wieso nicht? Ich würde hier keine Wertung vornehmen, sondern stur speichern, was vom Frontend geliefert wird.

Das hängt von der Fachlichkeit ab. Je nachdem hast Du ein unterschiedliches fachliches Datenmodell, und in der DB speicherst Du das Businessmodell, nicht die UI Werte. Die UI Werte können dem Modellinhalt entsprechen, müssen aber nicht.

FALLS Du die Aufgabe bekommst, die aktuellen Eingaben im UI speichern zu können, egal ob fachlich plausibel oder nicht, dann machst Du ein Datenmodell dafür und speicherst dieses. Das dürfte aber die Ausnahme sein.

Ist aber wurscht - es läuft immer auf's Gleiche hinaus: Die DB enthält das erforderliche fachliche Modell. Das UI präsentiert dem Anwender eine Sicht darauf. Eine solche Sicht kann sich nicht beliebig weit, aber doch ziemlich vom fachlichen Modell entfernen und trotzdem noch sinnvoll sein.

Deswegen gibt's keine Universalregel. Es gibt auch keine universelle Vorgehensweise. Wenn ich auf der grünen Wiese starte, beginne ich mit Usecases. "Was soll meine Anwendung können". Aus den Usecases entwickle ich normalerweise ein fachliches Modell, das die Daten aller Usecases konsistent aufnehmen kann. Daraus leite ich zum Anwender hin die UIs ab, als eine für den jeweiligen Usecase optimierte Sicht auf die Daten. Und ich leite zur DB hin das DB-Schema ab, das für die jeweilige DB optimale Zugriffe bietet.

Diese Methode ist teamorientiert. Man baut gemeinsam das Fachmodell, und dann kann man sich für die UIs und die DB aufteilen. Wenn man als Einzelkämpfer unterwegs ist, mag das anders aussehen.

Allerdings - man sollte das nicht zu strikt tun, sonst landet man beim Wasserfallmodell der 60er Jahre. Wasserfall ist für physische Bauten sinnvoll, wo es irre teuer ist, Komponenten abzureißen und neuzubauen. Bei Software ist das anders, deswegen kann man iterativ vorgehen. Dazu gibt's diverse, mehr oder weniger agile Vorgehensweisen. Und man sollte sich nicht schämen, wenn man einen Teil der Anwendung neu schreibt, nur weil man Fachanforderungen im Backlog findet, die mit dem aktuellen Modell nicht realisierbar sind. Das ist ganz normal. Software ist keine Raketentechnik. Dinge neu zu entwickeln ist billiger, als die 100% Lösung vorzuplanen. Solche Pläne erweisen sich fast immer als unbrauchbar. Fachvorgaben sind bewegliche Ziele. Man sollte nur drauf schießen, wenn sie nahe genug sind.

Rolf