nicht angemeldet
Ihr bekämt dann eine zusätzliche Schicht, die die Geschäftslogik und den Datenzugriff trennen würde.
Ist das nun gut oder schlecht?
Haha, it depends. Ich vermute, dass Eure Systeme genauso laufen wie die, die ich kenne, d.h. Geschäftslogik und Datenzugriff in den SPs auf dem Datenserver, die DB stellt also ein Gesamtsystem dar, an das nur noch das GUI anzubinden ist. Ich finde solche Systeme gut und leicht pflegbar.
Es gibt aber auch andere Leute, die dreischichtig denken und für die "3-tier", also Präsentations-, Geschäftslogik- und Persistenzschicht normal sind. Allerdings stammen diese Leute nach meiner Erfahrung oft aus dem Lager der Schwätzer und geben Angelerntes wieder ohne die Schierigkeit der Trennung von Datenzugriff und Geschäftslogik zu verstehen. Eigentlich ist doch jedes SELECT Datenzugriff und Geschäftslogik zugleich.
Bei Grosssystemen, die zudem verschiedene Datenservertypen nutzen, mag eine Geschäftslogikschicht Sinn machen, allerdings ist dann zwingend der SQL-Code nicht mehr so effizient und "gut". Hier bieten sich frameworks an, Hybernate und so. Allerdings sollte man schon wirklich sicher sein, dass die zusätzliche Schicht auch wirklich benötigt wird.
Wir erwarten uns von dem OO-Ansatz, dass der Prüfauwand kleiner wird, bzw. besser von der eigentlichen Funktionalität trennen kann, weil Objekte (entsprechend gut designed und programmiert) in sich immer konsistent sein sollten.
Welche Prüfungen sind denn da in den SPs? Das, was mir da so einfällt (Rechteabfragen, Historisierung) ist doch eher harmlos. Sind die Prüfungen anderer Art, also "reine" Geschäftslogik, so ist diese Komplexität eben erforderlich, da hilft auch keine Umverteilung auf eine neue Schicht. Ihr hättet dann sofort zigtausend Zeilen Code mehr und zudem das Problem mit der doppelten Haltung von Objekten in Geschäftslogikschicht und Persistenzschicht. Weiss nicht, wie leistungsfähig die Tools aus der "Programmierst Du noch oder modellierst Du schon?"-Generation sind.
SPs sind "eigentlich" gar nicht so schlecht wartbar, das Problem ist nur den Gesamtüberblick zu behalten.
Du hast recht, genau das ist derzeit unser Problem.
LOL
"Applikationserver" sind letzlich auch nur Komponenten, ich kenne den Java-Jargon auch nicht so recht, aber mich haben bzgl. Java hier im Forum einige Leute abgeschreckt.
Mein Problem ist, dass ich noch nicht sehen kann, wie diese Applikationsserver unsere Art von Anwendung verarbeiten können, da ich den Verdacht habe, dass diese Teile eher mit einem Webserver zu vergleichen sind als mit einer echten Server-Anwendung. Vor allem das Batchprozessing ohne Anstoß von aussen sehe ich noch nicht umsetzbar.
"ohne Anstoß von aussen" ist etwas für ständig laufende Dienste, also bspw. ein normaler Windows-Dienst oder diese "COM-Objekte" (MS hat da sowas, weiss nicht wie das genau heisst).
SOAP und webservices "reagieren", das ist richtig, vglb. mit einem Webserver.
Stell mal irgendwo ne Grafik ein und eine Datendesign-Skizze, zumal täten die Komponenten interessieren. Auserdem Prjektumfang, zu erwartende Last und der Abnhemerkreis.
Datendesign gibt es noch nicht. Es geht an sich um ein Logistik-System das Aufträge usw. verarbeitet.
Ne Skizze erscheint mir schon der Diskussion förderlich, aber natürlich nichts gegen brain storming. ;)