...es ist vielleicht auch nicht geschickt, auf der Ebene vom Üblichen aus zu argumentieren. Klar würde niemand, der ein paar Jahre mit dem Stoff arbeitet auf die Idee kommen, Geschäftslogik in die Datenbank zu schreiben. Aber ... es geht ja hier nicht um Dogmen, sondern darum, Ideen zu generieren, wie bestimmte Probleme gelöst werden können, um dann zu analysieren, welche Wege welche Konsequenzen (Vorteile, Nachteile, Grenzen) mit sich bringen - soweit man das eben absehen kann (für jede Veränderung ist es notwendig, den üblichen Weg zu verlassen und viele gute Ideen hatten Erfolg, obwohl nur wenige einzelne positive Konsequenzen dadurch vielleicht nur erahnten).
Dagegen spricht, gerade für Anfänger, dass es nunmal schon bewährte Lösunen für alle Möglichen Probleme und Aufgabenkomplexe gibt (Patterns, hier vielleicht MVC, PageController, whatever).
Letztlich ist es Wurscht, in welcher Form und noch mehr auf welchem Medium Programmlogik gespeichert wird. Wichtig ist halt, dass es taugt, einen zum angestrebten Ziel bringt. Allerdings hat es sich eben bewährt, Geschäftslogik von den Daten und ebenso von der Darstellungslogik strikt zu trennen. Das ist nicht immer sauber möglich, aber weitgehend schon. Der Sinn ist eben, dass alle Elemente bis auf die vorgegebenen Schnittstellen eben möglichst unabhängig voneinander Weiterentwickelt werden können. Wenn du Daten einfügen willst, dann mach es einfach. Wenn du die Geschäftslogik ändern möchtest, dann mach es einfach, ohne die Daten anpacken zu müssen (natürlich: um Änderungen des Datenmodells kommt man natürlich an bestimmten Punkten nicht drumrum). Das gleiche für die Darstellung.
Hast du Kontrollstrukturen in den Daten, dann wird es schwierig, diese nachträglich zu verändern. Außerdem wirst du sicherlich viele Redundanzen haben, da alle Datenobjekte vom gleichen Typ die gleiche Logik enthalten werden. Auch wird es schwierig, die Daten zu verändern, oder mit anderen Systemen als genau deinem zu berabeiten.
Basti |