Java vs. C# vs. PL/SQL

[Klaus Mock]

Hallo,

Ich versuche gerade aus mehreren Programmierkonzepten/Systemumgebungen für eine Neufassung einer Softwarelösung die optimale zu finden.

Die Ausgangslage:
Das derzeitige System, das in seiner Basis nunmehr schon ca. 9 Jahre auf dem Buckel hat, ist von der Geschäftslogik her fast vollständig mit PL/SQL umgesetzt. Der Hauptteil davon arbeitet mehr oder weniger selbständig. Das machen derzeitig C++-Prozesse, die entweder als Deamons arbeiten oder mittels cronjobs gestartet werden.

Das Benutzerinterface ist ein System mit einer .NET-Serveranwendung und darüber angebundene .NET-Clients die Windows.Forms benutzen (also keine Browseranwendung sondern eine Windows-Rich-Client-Anwendung). Diese Anwendung verwendet Datenbank-Views (deren Daten am Client in Form von ADO.NET Datatables verwaltet werden) bzw. -Stored-Procedures zur Interaktion mit der Oracle-DB.

Der größte Nachteil der Lösung ist, dass diese Anwendung für jedes Kundenprojekt angepasst werden muss, was dazu führt dass der PL/SQL-Code inzwischen schon recht komplex ist. Das ist natürlich für die Wartbarkeit bzw. Erweiterbarkeit nicht gerade zuträglich.

Da jetzt Anforderungen für zukünftige Projekte bestehen, die mit der derzeitigen Lösung nicht bzw. nur bedingt umgesetzt werden können, haben wir uns entschlossen der Anwendung ein Redesign angedeihen zu lassen.

Dabei haben wir uns auch die Frage gestellt, ob wir nicht die Businesslogik des Systems auch aus der Datenbank in eine Java bzw C# Anwendung herausziehen. Das vor allem im Hinblick darauf, das wir uns erwarten, dass eine OO Anwendung, vor allem wenn sie komponentenorientiert aufgebaut wird, wahrscheinlich hinsichtlich der Wart- bzw. Erweiterbarkeit wesentlich einfacher zu handhaben ist als das bestehende Konzept mit PL/SQL.

Egal, welches Konzept letztendlich verwendet wird, eines steht fest, und zwar das Benutzerinterface. Daran soll nichts geändert werden, außer allfällig notwendige Erweiterungen um mit OO-Systemen umgehen zu können, wobei wir versuchen werden, diese Anpassungen, wenn möglich, im neuen System zu implementieren.

Hier eine kurze, unvollständige Plus/Minus Aufstellung der einzelnen Konzepte, soweit ich sie beurteilen kann:

PL/SQL:

• Uns sehr gut bekannte Lösung, da das bisherige System darauf beruht
• An sich recht performant, da die Logik direkt bei den Daten in der Datenbank ausgeführt wird.
• Alle umliegenden Systeme (GUI) sind gut darauf abgestimmt.

• Schlechte Wartbarkeit der Stored Procedures
• Erweiterungen und Adaptierungen sind kompliziert, weil beispielsweise Vererbung in der Datenbank nicht oder nur eingeschränkt[1] möglich ist.

.NET und C#:

• Uns sehr gut bekannte Lösung, da wir schon sehr viel Erfahrung durch die GUI damit haben.
• Anbindung an das GUI-System sind recht einfach zu erledigen (.NET Remoting), da beide Systeme auf der gleichen Technologie beruhen würden.

• Läuft (wahrscheinlich) nur unter Windows[2]
• Damit verbunden ist ein psychologisches Problem, da es doch einige Leute gibt, die der Meinung sind, dass Server-Anwendungen unter Unix/Linux zu laufen haben.
• Im Vergleich zu den anderen beiden Lösungen gibt es recht wenig an Komponenten um eine solche Serveranwendung zu erstellen. (Beispiel: kein Applikationsserver, der den Namen verdienen würde)

Java bzw Java EE (5):

• Angeblich im Serverumfeld eine stabile Lösung, da J2EE bzw. Java EE doch schon einige Zeit verfügbar ist und sich inzwischen auch recht gut entwickelt hat.
• Applikationsserver, die schon einiges an Infrastruktur mitbringen, die man mit .NET selbst entwickeln müsste.
• Läuft auf vielen Plattformen

• Wir haben wenig bis keine Erfahrungen mit Java (könnte man aber mit zusätzlichen Mitarbeitern ausgleichen)
• Ich bin mir nicht sicher ob Applikationsserver für diese Art von Anwendungen geeignet sind, da alles was ich bisher darüber gelesen habe den Verdacht aufkommen ließ, dass es sich dabei um hochmotorisierte Webserver handelt (naja, nicht ganz, aber so ähnlich)

So, was meint ihr dazu? Was würdet ihr machen, und warum? Liege ich/wir komplett falsch mit unseren Überlegungen? Und überhaupt, wie macht man heutzutage so eine Software?

Ich danke euch im voraus schon für allfällige Hilfestellungen/Denkanstöße.

Grüße
  Klaus

[1] Ich weiß, dass Oracle auch Objekte und Vererbung kennt, aber ob das auch wirklich zielführend ist??
[2] Inwieweit Mono heute schon brauchbar für kommerzielle Anwendungen wie unsere ist, kann ich nicht beurteilen

[King^Lully]

Die Ausgangslage:
Das derzeitige System, das in seiner Basis nunmehr schon ca. 9 Jahre auf dem Buckel hat, ist von der Geschäftslogik her fast vollständig mit PL/SQL umgesetzt. Der Hauptteil davon arbeitet mehr oder weniger selbständig. Das machen derzeitig C++-Prozesse, die entweder als Deamons arbeiten oder mittels cronjobs gestartet werden.

Das Benutzerinterface ist ein System mit einer .NET-Serveranwendung und darüber angebundene .NET-Clients die Windows.Forms benutzen (also keine Browseranwendung sondern eine Windows-Rich-Client-Anwendung). Diese Anwendung verwendet Datenbank-Views (deren Daten am Client in Form von ADO.NET Datatables verwaltet werden) bzw. -Stored-Procedures zur Interaktion mit der Oracle-DB.

Der größte Nachteil der Lösung ist, dass diese Anwendung für jedes Kundenprojekt angepasst werden muss, was dazu führt dass der PL/SQL-Code inzwischen schon recht komplex ist. Das ist natürlich für die Wartbarkeit bzw. Erweiterbarkeit nicht gerade zuträglich.

Ihr habt Datenzugriff und Logik in die SPs gepackt, weil Logik und Datenzugriff schwer zu trennen ist.

Da jetzt Anforderungen für zukünftige Projekte bestehen, die mit der derzeitigen Lösung nicht bzw. nur bedingt umgesetzt werden können, haben wir uns entschlossen der Anwendung ein Redesign angedeihen zu lassen.

Dabei haben wir uns auch die Frage gestellt, ob wir nicht die Businesslogik des Systems auch aus der Datenbank in eine Java bzw C# Anwendung herausziehen.

Ihr bekämt dann eine zusätzliche Schicht, die die Geschäftslogik und den Datenzugriff trennen würde.

Das vor allem im Hinblick darauf, das wir uns erwarten, dass eine OO Anwendung, vor allem wenn sie komponentenorientiert aufgebaut wird, wahrscheinlich hinsichtlich der Wart- bzw. Erweiterbarkeit wesentlich einfacher zu handhaben ist als das bestehende Konzept mit PL/SQL.

Datendesign ist per se objektorientiert und objektbeziehungsorientiert. Ich wäre mit "OO und dann happy" vorsichtig.

Egal, welches Konzept letztendlich verwendet wird, eines steht fest, und zwar das Benutzerinterface. Daran soll nichts geändert werden, außer allfällig notwendige Erweiterungen um mit OO-Systemen umgehen zu können, wobei wir versuchen werden, diese Anpassungen, wenn möglich, im neuen System zu implementieren.

Kleinere Anpassungen vermutlich.

Hier eine kurze, unvollständige Plus/Minus Aufstellung der einzelnen Konzepte, soweit ich sie beurteilen kann:

PL/SQL:

• Uns sehr gut bekannte Lösung, da das bisherige System darauf beruht
• An sich recht performant, da die Logik direkt bei den Daten in der Datenbank ausgeführt wird.
• Alle umliegenden Systeme (GUI) sind gut darauf abgestimmt.

• Schlechte Wartbarkeit der Stored Procedures
• Erweiterungen und Adaptierungen sind kompliziert, weil beispielsweise Vererbung in der Datenbank nicht oder nur eingeschränkt[1] möglich ist.

SPs sind "eigentlich" gar nicht so schlecht wartbar, das Problem ist nur den Gesamtüberblick zu behalten. BTW - was soll sich vereerben? Entitäten sind sich zwar oft ähnlich, aber "Vererbung" macht es oft nicht leichter, eventuell ein Daten-Redeign in Betracht ziehen?!

.NET und C#:

• Uns sehr gut bekannte Lösung, da wir schon sehr viel Erfahrung durch die GUI damit haben.
• Anbindung an das GUI-System sind recht einfach zu erledigen (.NET Remoting), da beide Systeme auf der gleichen Technologie beruhen würden.

• Läuft (wahrscheinlich) nur unter Windows[2]
• Damit verbunden ist ein psychologisches Problem, da es doch einige Leute gibt, die der Meinung sind, dass Server-Anwendungen unter Unix/Linux zu laufen haben.
• Im Vergleich zu den anderen beiden Lösungen gibt es recht wenig an Komponenten um eine solche Serveranwendung zu erstellen. (Beispiel: kein Applikationsserver, der den Namen verdienen würde)

Liest sich ganz gut. Aber wo ist die Datenhaltung?  ;)

Java bzw Java EE (5):

• Angeblich im Serverumfeld eine stabile Lösung, da J2EE bzw. Java EE doch schon einige Zeit verfügbar ist und sich inzwischen auch recht gut entwickelt hat.
• Applikationsserver, die schon einiges an Infrastruktur mitbringen, die man mit .NET selbst entwickeln müsste.
• Läuft auf vielen Plattformen

• Wir haben wenig bis keine Erfahrungen mit Java (könnte man aber mit zusätzlichen Mitarbeitern ausgleichen)
• Ich bin mir nicht sicher ob Applikationsserver für diese Art von Anwendungen geeignet sind, da alles was ich bisher darüber gelesen habe den Verdacht aufkommen ließ, dass es sich dabei um hochmotorisierte Webserver handelt (naja, nicht ganz, aber so ähnlich)

"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.

So, was meint ihr dazu? Was würdet ihr machen, und warum? Liege ich/wir komplett falsch mit unseren Überlegungen? Und überhaupt, wie macht man heutzutage so eine Software?

Ich danke euch im voraus schon für allfällige Hilfestellungen/Denkanstöße.

Stell mal irgendwo ne Grafik ein und eine Datendesign-Skizze, zumal täten die Komponenten interessieren. Auserdem Prjektumfang, zu erwartende Last und der Abnhemerkreis.

[King^Lully]

Der größte Nachteil der Lösung ist, dass diese Anwendung für jedes Kundenprojekt angepasst werden muss, was dazu führt dass der PL/SQL-Code inzwischen schon recht komplex ist. Das ist natürlich für die Wartbarkeit bzw. Erweiterbarkeit nicht gerade zuträglich.

Das liest sich merkwürdig. Was ist da genau das Problem?

Sollte es so sein, dass für verschiedene Kunden verschiedene Anpassungen vorzunehmen sind, die aber jeweils das Gesamtsystem betreffen. Wird dieses allmählich darum zu komplex?

Und ihr wollt ggf. dann das Gesamtsystem splitten (Komponenten) und so die Komplexität mindern (was wohl nicht geht) und besser verteilen?

Wie ist denn das Thema Komplexität mit den Abnehmern diskutiert? Erkennen diese ggf., dass die o.g. "Kundenprojekte" immer mehr Komplexität hinzubauen?

[Klaus Mock]

Hallo King^Lully,

Zuerst Danke für die Antwort.

Ihr habt Datenzugriff und Logik in die SPs gepackt, weil Logik und Datenzugriff schwer zu trennen ist.

Ja, das ist ja an sich der klassische Ansatz.

Ihr bekämt dann eine zusätzliche Schicht, die die Geschäftslogik und den Datenzugriff trennen würde.

Ist das nun gut oder schlecht?
Die Idee ist, in der Geschäftslogik mit Objekten zu arbeiten, die dann von einer Persistenzschicht in die Datenbank geschrieben wird.
Bei SPs hat man ja die Situation, dass man, wenn man die Funktionalität in kleinere Einheiten aufteilt (um beispielsweise das Code-Duplizieren zu vermeiden), diese in sich konsistent halten sollte. Was allerdings bedeutet, dass man in diesen Prozeduren sehr viele Kostistenz- bzw. Kontextprüfungen durchführt. Die SPs neigen dann dazu dass der meiste Code Prüfaufgaben hat und die eigentlichen Arbeitsanweisungen (die dann den Datenbestand bearbeiten) eher in dem Prüfcode untergehen. Die Alternative dazu wäre, dass man in Oracle entweder mit Object-Typs arbeitet oder aber sehr viele Übergabeparameter braucht.

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.

Datendesign ist per se objektorientiert und objektbeziehungsorientiert. Ich wäre mit "OO und dann happy" vorsichtig.

Natürlich wissen wir, dass OO alleine noch nicht das allein seeligmachende ist;-)

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.

BTW - was soll sich vereerben? Entitäten sind sich zwar oft ähnlich, aber "Vererbung" macht es oft nicht leichter, eventuell ein Daten-Redeign in Betracht ziehen?!

Eine Anwendung, so wie wir das im Kopf haben, besteht eben nur zum geringeren Teil aus Entitäten. Eine Menge Funktionalität wäre in sog. Controller-Klassen unterzubringen, die dann mit den Entitäten umgehen. die Entitäten und deren Beziehung zueinander ist eigentlich fast immer konstant bei den einzelnen Projekten. Lediglich Attribute können dazukommen (wobei diese meist nicht aktive Attribute sind, sondern eher für Reports und ähnliches benötigt werden).
Die gravierenden Änderungen sind meist in den Funktionen, die mit diesen Entitäten arbeiten. Und hier kommt es oft vor, dass man diese Funktionalität von der bestehenden ableitet und nur an den notwendigen STellen modifiziert. Und da machen sich OO-Ansätze wie Vererbung oder Interfaces usw. an sich recht gut.

Liest sich ganz gut. Aber wo ist die Datenhaltung?  ;)

Das soll eine Persistenzschicht wie z. B. Hibernate erledigen.

"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.

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. Bezüglich der Last ist das auch so eine Sache, da ich hier zu wenig über die eigentliche Natur der Anwendung sagen kann.  Nur so viel, dass mind. 150-200.000 Aufträge täglich über das System laufen sollen. Das klingt vielleihct etwas wenig, allerdings ist es die interne Verarbeitung dieser Aufträge, die sehr aufwendig sein kann.

Grüße
  Klaus

[King^Lully]

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.   ;)

[Frank (no reg)]

Hallo Klaus,

bei einer Verbandelung von .Net Client-Applikation (die soll ja so bestehen bleiben) mit einem Java-Applikationsserver, würde ich vorab die Interoperabilität überprüfen - Datentypen, Datenaustauschprotokolle (SOAP??).

Grundsätzlich ist es nicht schlecht sondern sogar ganz praktisch, eine gewisse Menge Logik in der Datenschicht zu haben, die die Datenhaltung unterstützt. (Das verstehen aber einige selbsternannte OO-Software-Projektleiter-Helden nicht, die möchten gern alle Daten gleich und immer in .Net Objekten haben. Ich hoffe, dass diese bald aussterben ;)) Zurück zum Thema: Was für Operationen tut ihr so in diesen PL/SQL SPs?

Stichwort Remoting: Keine dumme Idee, zumal man auch "Eventing" und andere bi-direktionale Kommunikation einflechten könnte.

Stichwort Applikationsserver: Was hättet ihr an Infrastrukturaufgaben, die abgefackelt werden könnten:

• Logging
• Access Right Managment
• Auditing
• Historizing
  Wo sind diese Dinge momentan implementiert?

Stichwort Datenbank: Wie gedenkt ihr die PL/SQL Sachen zu entflechten? Steht ein Datenbank-Refactoring ebenfalls zur Debatte?

Grüsse, man liest sich, Frank

PS: .Net Frontend mit .Net Serverkomponenten vertragen sich für gewöhnlich ganz gut.

[Klaus Mock]

Hallo Frank,

Danke erst einmal für Deine Anregungen.

bei einer Verbandelung von .Net Client-Applikation (die soll ja so bestehen bleiben) mit einem Java-Applikationsserver, würde ich vorab die Interoperabilität überprüfen - Datentypen, Datenaustauschprotokolle (SOAP??).

Das ist mir bewusst. Gerade SOAP neigt ja dazu, bei größerer Last ein Problem zu werden, das XML an sich geschwätzig ist und somit zusätzliche Last in der Kommunikation und an den Endpunkten derselben erzeugt (Stichwort Serialisierung/Deserialisierung).

Grundsätzlich ist es nicht schlecht sondern sogar ganz praktisch, eine gewisse Menge Logik in der Datenschicht zu haben, die die Datenhaltung unterstützt. (Das verstehen aber einige selbsternannte OO-Software-Projektleiter-Helden nicht, die möchten gern alle Daten gleich und immer in .Net Objekten haben. Ich hoffe, dass diese bald aussterben ;))

Das möchte ich nicht kommentieren;-)
Aber Du triffst den Nagel auf den Kopf, da es auch bei uns die beiden Lager gibt, die einen, die meinen "OO wird'S schon richten" und die anderen die den Standpunkt haben "Nur die Datenbank ist das einzig Wahre".
Ich allerdings vertrete den Standpunkt "Kommt darauf an". Mein Problem bei der Sache ist, dass ich das noch nicht so richtig Anschätzen kann. Ich bin zwar der Überzeugung, dass man mit jeder von mir angesprochenen Architektur das Problem lösen kann, allerdings weiss ich noch nicht, welche die für uns optimale ist.
Deshalb frage ich ja hier nach, da sich immer einige hier herumtreiben, die scheinbar schon einiges an Erfahrung mit den jeweiligen Technolohgien haben.

Zurück zum Thema: Was für Operationen tut ihr so in diesen PL/SQL SPs?

Grundsätzlich alles, was irgendwie die Daten manipuliert. Es gilt, dass keine Clientanwendung (GUI und Hintergrundprozesse) direkt DML-Statements absetzen dürfen.
Die Funktionalität reicht von simplen INSERT/UPDATE/DELETE-Prozeduren bis hin zu komplexen Verarbeitungen von vielen Datensätzen.

Stichwort Applikationsserver: Was hättet ihr an Infrastrukturaufgaben, die abgefackelt werden könnten:

• Logging
• Access Right Managment
• Auditing
• Historizing
  Wo sind diese Dinge momentan implementiert?

Das ist unterschiedlich. Jedes beteiligte Subsystem hat bspw. sein eigenes Logging. ARM wird über das GUI-System erledigt, Auditing z.T. auch. Historizing machen, falls notwendig, die Subsysteme selbst.

Stichwort Datenbank: Wie gedenkt ihr die PL/SQL Sachen zu entflechten? Steht ein Datenbank-Refactoring ebenfalls zur Debatte?

PL/SQL soll, so ist die Idee, vollständig von der OO-Implementierung abgelöstt werden. Und ein Redesign der DB ist Teil des Projekts.

Grüße
  Klaus

[Frank (no reg)]

Hi Klaus,

Danke erst einmal für Deine Anregungen.

Gern geschehen. :)

Betreffend SOAP, XML und De/Serialisierung: Je nach verfügbaren Technologien und Programmierwissen kann man dort ziemlich gut optimieren, wenn es auf Datendurchsatz ankommt.

Und .Net Remoting erlaubt sowieso die performantere binäre Serialisierung von Objekten. Mit .Net 2.0 wird binäre Serialsiierung auch von DataSets unterstützt.

Das Wort "Subsystem" ist etwas neu in deiner Schilderung :) Was meinst du damit?

Grüsse
Frank

[Daniel Thoma]

Hallo Klaus,

die eigentliche Logik des Datenmodells (Konsistenz der Daten sichern, den jeweils notwendigen Objekt-Teilgraphen auswählen, etc.) sollte definitiv in der Datenbankschicht implementiert werden.
Diese Logik brauchen alle auf der Datenbank aufbauenden Anwendungen (falls es mehrere geben sollte, wobei man sich darüber streiten kann, ob das gut ist), es ist meist wesentlich Performanter, das in der Datenbank zu erledigen und es macht Anwendungen meist unübersichtlich, wenn man diese Logik aus dem Datenmodell, das nunmal in der DB liegt, herauszieht.

Bei vielen Wirtschaftsanwendungen gibt es darüber schon gar keine Geschäftslogik mehr sondern nur noch eine Präsentationsschicht. Wenn es keine gibt, sollte man sich auch keine ausdenken ;-)
Gibt es welche (Anbindung anderer Systeme, Realisierung irgendwelcher Arbeitsabläufe, komplexere Auswertung der Daten also im Sinne von irgendwas Simulieren/Berechnen (eher selten nach meinem Eindruck in der Wirtschaft)) dann ist eine Zwischenschicht, die das erledigt, und nicht in der Datenbank implementiert ist, sinnvoll.

Nun stellt sich die Frage, in welcher Technologie man das tut. Nachdem ich nun etwas C# verwendet habe, scheint mir Java angenehmer, weil die Klassenbibliothek ausgereifter ist. Das fängt schon mit Datenstrukturen an, bei .NET fehlt einfach einiges.
Für C# spricht allerdings sehr stark, dass ihr Euch damit auskennt und dass ihr schon ein Teil der Anwendung damit realisiert habt. Eine weitere Sprache verhindert effektiv die Wiederverwendung bestehenden Codes. Außerdem ist die Kommunikation in heterogenen Anwendungen praktisch immer etwas umständlicher zu handhaben.

Was Application-Server, Komponentenkonzepte (JEE) usw angeht, würde ich vorsichtig sein. Diese Dinge haben alle ihren Zweck und sind hilfreich, allerdings nur, wenn man sie auch versteht und das kostet Zeit und Aufwand.
Wenn ihr also nicht die Zeit oder das Geld habt, Euch in komplexe, neue Technologie einzuarbeiten, kann es besser sein, es zu lassen.
Nichts versaut eine Architektur eines Systems meiner Meinung nach zuverlässiger, als Technologie, die man nicht verstanden hat.

Grüße

Daniel

[King^Lully]

Bei vielen Wirtschaftsanwendungen gibt es darüber schon gar keine Geschäftslogik mehr sondern nur noch eine Präsentationsschicht.

Nichts versaut eine Architektur eines Systems meiner Meinung nach zuverlässiger, als Technologie, die man nicht verstanden hat.

Ganz können Wir Dir da nicht zustimmen, aber grundsätzlich sind solche etwas würzigen Aussagen schon OK.   ;)

[Klaus Mock]

Hallo,

die eigentliche Logik des Datenmodells (Konsistenz der Daten sichern, den jeweils notwendigen Objekt-Teilgraphen auswählen, etc.) sollte definitiv in der Datenbankschicht implementiert werden.

Genau da gibt es ja die zwei Konzepte "Alles in der DB" und "die DB ist nur ein dummer Storage von Daten".
Wie weiter unten schon erwähnt habe, soll die Datenbank über eine Persistenz-Schicht (Hibernate oder Toplink oder ähnliches) verwaltet werden. Das bedeutet letztendlich dass die Datenbank an sich im hier diskutierten OO-Konzept eine untergeordnete Rolle übernimmt und nicht, so wie beim PL/SQL-Ansatz, die Hauptrolle spielt.

Diese Logik brauchen alle auf der Datenbank aufbauenden Anwendungen (falls es mehrere geben sollte, wobei man sich darüber streiten kann, ob das gut ist), es ist meist wesentlich Performanter, das in der Datenbank zu erledigen und es macht Anwendungen meist unübersichtlich, wenn man diese Logik aus dem Datenmodell, das nunmal in der DB liegt, herauszieht.

Ist es nicht so, dass wenn man eine Sammlung von Entitäts-Objekten, die dann persistiert werden können, in seinen Anwendungen verwendet, die Logik in der Datenbank praktisch vollständig entfallen kann?
Die Performance ist eine andere Geschichte. Betrachtet man nur den Datenzugriff und dessen Ausführungsgeschwindigkeit, so ist die DB sicherlich unschlagbar.
Andererseits ist ein Aspekt der Softwareentwicklung auch die Performance bei der Entwicklung selbst bzw. die Anpassungsfähigkeit eines Softwaresystems, wie das von dem wir hier reden. Das dabei auhc kommerzielle Überlegungen eine Rolle spielen sollte eigentlich auch klar sein.

Ein Zeil des Redesigns unserer Software ist es eben auch, dass wir schlagkräftiger bei der Umsetzung von Kundenprojekten  und den damit verbundenen Anpassungen werden.

Bei vielen Wirtschaftsanwendungen gibt es darüber schon gar keine Geschäftslogik mehr sondern nur noch eine Präsentationsschicht. Wenn es keine gibt, sollte man sich auch keine ausdenken ;-)

Da ahben wir anscheinend unterschiedliche Erfahrungen gemacht, vorausgesetzt ich haben Dich richtig verstanden.

Gibt es welche (Anbindung anderer Systeme, Realisierung irgendwelcher Arbeitsabläufe, komplexere Auswertung der Daten also im Sinne von irgendwas Simulieren/Berechnen (eher selten nach meinem Eindruck in der Wirtschaft)) dann ist eine Zwischenschicht, die das erledigt, und nicht in der Datenbank implementiert ist, sinnvoll.

Genau die von Dir genannten Beispiele sind unser tägliches Brot. Und ich denke doch dass wir eine eher typische Wirtschaftsanwendung entwicklen.

Nun stellt sich die Frage, in welcher Technologie man das tut. Nachdem ich nun etwas C# verwendet habe, scheint mir Java angenehmer, weil die Klassenbibliothek ausgereifter ist. Das fängt schon mit Datenstrukturen an, bei .NET fehlt einfach einiges.

Kannst Du das genauer erklären? Ich habe auch das Gefühl, dass Java serverseitig weiter ist, aber GEfühl alleine reicht hier nicht.

Für C# spricht allerdings sehr stark, dass ihr Euch damit auskennt und dass ihr schon ein Teil der Anwendung damit realisiert habt.

Du sagst es.

Eine weitere Sprache verhindert effektiv die Wiederverwendung bestehenden Codes.

Die Wiederverwendbarkeit von Code ist nebensächlich, da das bestehende C#-System eine vollkommen andere Aufgabenstellung hat (es ist unser GUI-System). Eigentlich ist eine weitgehende Entkoppelung des GUI-Systems von der hier besprochenen Anwendung sogar gewünscht, da das GUI-System eine recht generischen Ansatz verfolgt.

Außerdem ist die Kommunikation in heterogenen Anwendungen praktisch immer etwas umständlicher zu handhaben.

Das ist uns bewusst. Allerdings sollen gerade mit dem GUI-System eher primitive Datentype ausgetauscht werden (also Strings, div. numerische Typen, Datumswerte usw.) da das GUI-System stark auf den ADO.NET-DataTables beruht.

Was Application-Server, Komponentenkonzepte (JEE) usw angeht, würde ich vorsichtig sein. Diese Dinge haben alle ihren Zweck und sind hilfreich, allerdings nur, wenn man sie auch versteht und das kostet Zeit und Aufwand.
Wenn ihr also nicht die Zeit oder das Geld habt, Euch in komplexe, neue Technologie einzuarbeiten, kann es besser sein, es zu lassen.

Da es sich bei dem Redesign um eine grundlegende Richtungsentscheidung handelt, ist der Aufwand für die Einarbeitung nicht so bestimmend, so lange es sich nicht um mehrere Mannjahre handelt;-) Aber so im Bereich von einigen Monaten darf das durchaus liegen. Und seien wir uns ehrlich, irgendwann haben wir uns ja auch das erste Mal mit SQL bzw. SPs auseineandersetzen müssen. Und das versteht man auch nicht vom ersten Tage an.

Nichts versaut eine Architektur eines Systems meiner Meinung nach zuverlässiger, als Technologie, die man nicht verstanden hat.

Wie wahr. Deshalb wollen wir die Entscheidung auch nicht von jetzt auf gleich treffen. Wir versuchen eher, so viel von der Technologie wie möglich zu verstehen, bevor wir damit die eigentliche Umsetzung beginnen.

Grüße
  Klaus

[Daniel Thoma]

Hallo Klaus,

Genau da gibt es ja die zwei Konzepte "Alles in der DB" und "die DB ist nur ein dummer Storage von Daten".

Beide Ansätze sind meiner Meinung nach falsch, die Lösung liegt wie meistens irgendwo in der Mitte ;-)

Wie weiter unten schon erwähnt habe, soll die Datenbank über eine Persistenz-Schicht (Hibernate oder Toplink oder ähnliches) verwaltet werden. Das bedeutet letztendlich dass die Datenbank an sich im hier diskutierten OO-Konzept eine untergeordnete Rolle übernimmt und nicht, so wie beim PL/SQL-Ansatz, die Hauptrolle spielt.

Das führt aber leicht zur klassischen alle-daten-rein-und-raus Anwendung, die bei jedem Start/jeder Sitzung/... einen riesigen Objektgraphen erzeugt und wieder zurückschreibt.
Ich bin durchaus für den Einsatz solcher Mappingschichten, man sollte aber auch deren Möglichkeiten nutzen, genau die Objekte aus der Datenbank zu holen, die man braucht. Wenn dazu an einigen stellen Stored Procedures notwendig sind, sollte man davor meiner Meinung nach nicht zurückschrecken.

Andererseits ist ein Aspekt der Softwareentwicklung auch die Performance bei der Entwicklung selbst bzw. die Anpassungsfähigkeit eines Softwaresystems, wie das von dem wir hier reden. Das dabei auhc kommerzielle Überlegungen eine Rolle spielen sollte eigentlich auch klar sein.

Klar, aber so gigantisch ist ja die Funktionalität die man in der DB haben sollte nicht. Es geht eigentlich nur um die sinnvolle Verwendung von Queries  und evtl. einige Stored Procedures um diese zu ergänzen und evtl. um die Daten konsistent zu halten (Trigger etc).
Konsistenz und Suche der Daten sind aufgaben eines Datenmodells und das liegt nunmal in der Datenbank. Erledigt man die Konsistenzsicherung wo anders, besteht die Gefahr, dass die Datenbank inkonsistent wird, erledigt man die Suche wo anders, hat man schnell massive Performance und Speicherprobleme.
Sicher kann man sich manchmal im Detail streiten, ob eine Auswahl oder Suche nicht über den Aufgabenbereich eines Datenmodells hinausgeht und herausgezogen werden kann oder sollte. Aber um solche Grenzfälle geht es mir nicht. Wichtig ist, dass man im großen und ganzen nur Daten auf Objekte abbildet, die man dann auch tatsächlich braucht.

Ein Zeil des Redesigns unserer Software ist es eben auch, dass wir schlagkräftiger bei der Umsetzung von Kundenprojekten  und den damit verbundenen Anpassungen werden.

Dazu kann man nicht viel sagen, ohne das Datenmodell zu kennen.
Vielleicht kann man das Datenmodell so entwerfen, dass es flexibel genug für alle Anforderungen ist? Oder man kann Erweiterungspunkte vorsehen, gerade mit Hibernate u.ä. geht das auch ganz gut, da man die Abbildungen nicht zentral definieren muss.

Bei vielen Wirtschaftsanwendungen gibt es darüber schon gar keine Geschäftslogik mehr sondern nur noch eine Präsentationsschicht. Wenn es keine gibt, sollte man sich auch keine ausdenken ;-)
Da ahben wir anscheinend unterschiedliche Erfahrungen gemacht, vorausgesetzt ich haben Dich richtig verstanden.

Ich hab' nicht viel praktische Erfahrung (studiere noch) ich betrachte das also alles eher von außen.
Es gibt aber nach meinem Eindruck eine gewisse Klasse von Verwaltungsanwendungen, die im Wesentlichen Daten erfassen und Daten anzeigen. Eine eigentliche Anwendungslogik gibt es da praktisch nicht.
Dann gibt es natürlich Systeme, die ein Teil der Verwaltung automatisieren, hier gibt es dann Anwendungslogik, die idR. auch noch sehr spezifisch ist und flexibel anpassbar sein muss. Das ist der Bereich, in dem zur Zeit Workflow-Engines u.ä. populär sind.

Genau die von Dir genannten Beispiele sind unser tägliches Brot. Und ich denke doch dass wir eine eher typische Wirtschaftsanwendung entwicklen.

Ich wollte nicht sagen, dass diese Anwendungen untypisch sind. Aber es gibt eben auch die genannte einfachere Klasse.

Nun stellt sich die Frage, in welcher Technologie man das tut. Nachdem ich nun etwas C# verwendet habe, scheint mir Java angenehmer, weil die Klassenbibliothek ausgereifter ist. Das fängt schon mit Datenstrukturen an, bei .NET fehlt einfach einiges.
Kannst Du das genauer erklären? Ich habe auch das Gefühl, dass Java serverseitig weiter ist, aber GEfühl alleine reicht hier nicht.

.NET hat zum Beispiel keine Sets, es gibt keine Maps (heißen da Directories) die nur lesbar sind (bei Listen geht das aber), die Reflection-Schnittstelle ist nicht generisch, obwohl C# das untersützt etc. Das sind die Sachen über die ich bisher so gestolpert bin. Mein Eindruck war, dass die Klassenbibliothek einfach (noch nicht) so rund ist. Mit den darauf aufbauenden Technologien hat das erstmal gar nichts zu tun.

Die Wiederverwendbarkeit von Code ist nebensächlich, da das bestehende C#-System eine vollkommen andere Aufgabenstellung hat (es ist unser GUI-System). Eigentlich ist eine weitgehende Entkoppelung des GUI-Systems von der hier besprochenen Anwendung sogar gewünscht, da das GUI-System eine recht generischen Ansatz verfolgt.

Naja oft hat man dennoch irgend welche Bibliotheken oder so entwickelt oder braucht bestimmte Datenmodelle auch auf der Clientseite etc. Das hab ich erst neulich bei einer Simulationsanwendung der Uni gesehen. Da gibt es einen Kern und verschiedene Clients. Alle benötigen Objekte für die Daten, die sie untereinander austauschen. Im Prinzip könnte man da eine saubere API für schreiben, leider wird C#, Java und C++ eingesetzt, was bei Änderungen an den ausgetauschten Daten gleich den dreifachen Anpassungsaufwand bedeutet. Man sollte sich also gut überlegen, ob es wirklich keine Überschneidungen gibt. Eine XML-Schnittstelle oder so dazwischen ist kein Grund, die gibt es da auch.

Und seien wir uns ehrlich, irgendwann haben wir uns ja auch das erste Mal mit SQL bzw. SPs auseineandersetzen müssen. Und das versteht man auch nicht vom ersten Tage an.

Ja, ich hab' nur schon ab und an mal gesehen, dass jemand nach nem Tutorial eine JEE-Anwendung gebaut hat ;)
Aber wenn ihr bereit seid, da ein paar Monate zu investieren, ist es sicher eine gute Idee, sich sowohl in die JEE-Welt als auch in die entsprechenden MS-Produkte einzuarbeiten und zu vergleichen.
Wenn die GUI nicht so wichtig ist und ihr sonst noch keine größeren Systeme auch .NET-Basis gebaut habt, ist Java sicher noch gut im rennen.

Wie wahr. Deshalb wollen wir die Entscheidung auch nicht von jetzt auf gleich treffen. Wir versuchen eher, so viel von der Technologie wie möglich zu verstehen, bevor wir damit die eigentliche Umsetzung beginnen.

Ein lobenswerter Vorsatz ;-)

Grüße

Daniel

[King^Lully]

Genau da gibt es ja die zwei Konzepte "Alles in der DB" und "die DB ist nur ein dummer Storage von Daten".
Beide Ansätze sind meiner Meinung nach falsch, die Lösung liegt wie meistens irgendwo in der Mitte ;-)

Die Ansätze schliessen einander aus.

Klar, aber so gigantisch ist ja die Funktionalität die man in der DB haben sollte nicht. Es geht eigentlich nur um die sinnvolle Verwendung von Queries  und evtl. einige Stored Procedures um diese zu ergänzen und evtl. um die Daten konsistent zu halten (Trigger etc).

Vorsicht bei Triggern. Diese Objekte - und das kann nicht oft genug betont werden - haben eigentlich nichts in der DB zu suchen, werden aber für systemfremde Zwecke, bspw. für das controlling, benötigt und sind deshalb im RDBMS implementiert.

Ein Zeil des Redesigns unserer Software ist es eben auch, dass wir schlagkräftiger bei der Umsetzung von Kundenprojekten  und den damit verbundenen Anpassungen werden.
Dazu kann man nicht viel sagen, ohne das Datenmodell zu kennen.

Genau, das ist der Knackpunkt, welche "Kundenprojekte" generieren warum Komplexität? Eventuell gibt es da ganz andere Lösungen als die bisher angedachten.

Ich hab' nicht viel praktische Erfahrung (studiere noch) ich betrachte das also alles eher von außen.

Ist ja noch blosses brain storming, da sind alle Meinungen hilfreich. "Fast alle Meinungen" war natürlich gemeint.

Es gibt aber nach meinem Eindruck eine gewisse Klasse von Verwaltungsanwendungen, die im Wesentlichen Daten erfassen und Daten anzeigen. Eine eigentliche Anwendungslogik gibt es da praktisch nicht.

Hast Du schon mal geschrieben sowas, das zeugt von Unverständis bzgl. des Begriffs SW. Denke mal darüber nach warum es SW gibt und was diese genau unterstützt. BTW - SW ist (auch konzeptionell) etwas ganz anderes als das was im Wilden Westen SW war.

[Daniel Thoma]

Hallo King^Lully,

Die Ansätze schliessen einander aus.

Wieso? Was spricht dagegen, SQL zweckmäßig einzusetzen und komplexe Queries evtl. durch Stored Procedures zu ergänzen, ohne gleich alles in der DB abzuhandeln? Gänge Objekt-Relation-Mapper unterstützen diesen Ansatz ja auch.

Vorsicht bei Triggern. Diese Objekte - und das kann nicht oft genug betont werden - haben eigentlich nichts in der DB zu suchen, werden aber für systemfremde Zwecke, bspw. für das controlling, benötigt und sind deshalb im RDBMS implementiert.

Naja man kann die falls notwendig zur Konsistenzsicherung einsetzen (irgendwas löschen, wenn was anderes gelöscht wird). Kann natürlich auch sein, dass man das von einem Objekt-Realtion-Mapper erledigen lassen kann. Diese zwei Ebenen sind auch schwer zu trennen und eher technischer als konzeptioneller Architektur. Eigentlich ist es aus Programmierersicht egal, ob eine DB oder der Mapper irgend etwas erledigt. Das passiert halt irgendwo "unten".

Ist ja noch blosses brain storming, da sind alle Meinungen hilfreich. "Fast alle Meinungen" war natürlich gemeint.

Ich bin durchaus arrogant genug, meine Meinung auch ohne so umfangreiche Erfahrung als wichtig anzusehen. Erfahrung bringt es meiner Erfahrung nach sowieso nicht so wahnsinnig, vor allem, wenn man sich im wesentlichen nur mit einem Typ von Software beschäftigt hat... ;-)

Hast Du schon mal geschrieben sowas, das zeugt von Unverständis bzgl. des Begriffs SW.

»»»» 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.
Ich rede genau von Deinen 2-Tier Anwendungen. Es gibt da ein Bisschen Datenverwaltung (vielleicht auch ein Bisschen viel Datenverwaltung) und darüber nur noch GUI. Unter Geschäftslogik verstehe ich Arbeitsabläufe, möglicherweise auch Systemübergreifende. Das dürfte der Fall bei den von Dir Angesprochenen "Großsystemen" sein. Natürlich mag man auch in mancher reinen Datenbankanwendung ein bisschen Geschäftslogik in diesem Sinne finden, und deren geringer Umfang mag es rechtfertigen, das nicht rauszuziehen. Ich rede aber von Fällen, in denen die Abläufe selbst eine ernstzunehmende Komplexität erreichen und es nicht nur um die Daten geht.

Denke mal darüber nach warum es SW gibt und was diese genau unterstützt.

Danke für den Tipp, ich hab mich schon gelegentlich mit Software und deren Strukturierung beschäftigt.

Grüße

Daniel

[King^Lully]

Die Ansätze schliessen einander aus.
Wieso? Was spricht dagegen, SQL zweckmäßig einzusetzen und komplexe Queries evtl. durch Stored Procedures zu ergänzen, ohne gleich alles in der DB abzuhandeln? Gänge Objekt-Relation-Mapper unterstützen diesen Ansatz ja auch.

Wenn ich Hybnerate und ähnliche Tools richtig verstanden habe, dann modelliert man die Logik und Hybernate generiert lauen SQL-Code. Das muss nicht so schlecht sein.
Die prinzipielle Alternative besteht darin alles ausser dem GUI in die DB zu legen.
Ein Mischmasch wäre in meinen Augen die aufwendigste und schlechteste Lösung.
Mag sein, dass das unter ganz besonderen Umständen erforderlich ist, also die Hybnernate-"Hilfe" nicht zu nutzen und alles selbst zu schreiben. Nichtsdestotrotz schliessen sich die Ansätze aus, d.h. wir hätten einen dritten Ansatz, den ich zudem nicht mag.

Vorsicht bei Triggern. Diese Objekte - und das kann nicht oft genug betont werden - haben eigentlich nichts in der DB zu suchen, werden aber für systemfremde Zwecke, bspw. für das controlling, benötigt und sind deshalb im RDBMS implementiert.
Naja man kann die falls notwendig zur Konsistenzsicherung einsetzen (irgendwas löschen, wenn was anderes gelöscht wird).

Genau dagegen sprach ich mich aus. In der Praxis entstehen so debilste Systeme. Wir merken uns: Keine Trigger einsetzen, ausser für controlling Zwecke wie bspw. alerts.

Kann natürlich auch sein, dass man das von einem Objekt-Realtion-Mapper erledigen lassen kann. Diese zwei Ebenen sind auch schwer zu trennen und eher technischer als konzeptioneller Architektur. Eigentlich ist es aus Programmierersicht egal, ob eine DB oder der Mapper irgend etwas erledigt. Das passiert halt irgendwo "unten".

Das sehe ich ganz anders, das ist eben nicht "egal".

Erfahrung bringt es meiner Erfahrung nach sowieso nicht so wahnsinnig, vor allem, wenn man sich im wesentlichen nur mit einem Typ von Software beschäftigt hat... ;-)

Mit dem Typ von SW, die Geschäftslogik nun mal fordert, die Geld bringt so zu sagen. Wir diskutieren hier ja ausdrücklich nicht "SpezialSW" wie bspw. Browser, Grafikprogramme oder Spiele.

Ich rede genau von Deinen 2-Tier Anwendungen. Es gibt da ein Bisschen Datenverwaltung (vielleicht auch ein Bisschen viel Datenverwaltung) und darüber nur noch GUI. Unter Geschäftslogik verstehe ich Arbeitsabläufe, möglicherweise auch Systemübergreifende. Das dürfte der Fall bei den von Dir Angesprochenen "Großsystemen" sein. Natürlich mag man auch in mancher reinen Datenbankanwendung ein bisschen Geschäftslogik in diesem Sinne finden, und deren geringer Umfang mag es rechtfertigen, das nicht rauszuziehen. Ich rede aber von Fällen, in denen die Abläufe selbst eine ernstzunehmende Komplexität erreichen und es nicht nur um die Daten geht.

Du unterliegst dem krassen Missverständnis, dass "VerwaltungsSW" nicht komplex ist. Per se nicht komplex, LOL.

Denke mal darüber nach warum es SW gibt und was diese genau unterstützt.
Danke für den Tipp, ich hab mich schon gelegentlich mit Software und deren Strukturierung beschäftigt.

Als Studi wäre ich da vorsichtiger.   ;)