nicht angemeldet
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