ERM vs Objektorientierung

[mosquito87]

Hallo zusammen,

bin gerade dabei, eine Webanwendung zu designen und noch in der Planungsphase.
Das ERM-Diagramm steht schon mal ...
Nun frage ich mich aber, wie ich dieses auf die objektorientierten Prinzipien übertrage.

Beispiel:
Ich habe 1 Kunden, der in Besitz vieler Rechnungen ist.

Genau genommen benötige ich nun die Klasse "Kunde" mit einem Attribut, das beliebig viele Rechnungen speichern kann (Collection).
Soweit korrekt?
Doch warum der Aufwand? Vielleicht will ich nur die Hauptdaten des Kunden anzeigen. Dann wäre es sinnlos, dieses Attribut mit all den Rechnungen zu füllen (aus Performancegründe).
Ich könnte auch auf das Attribut verzichten, und die Klasse "Rechnung" nur anhand der ID des Kunden (Fremdschlüssel) erzeugen. Wäre aber nicht mehr 100% objektorientiert.

Was sind hier die Best Practices? Wo kann man sich diesbzgl. einlesen?

 

[Yuuri]

Du entwirfst die Klasse allgemeingültig. Kunden, welche nur eine oder spezielle Rechnung(en) enthalten, haben dann eben nur ein Element in der Collection (C#?). Du kannst auch einen Konstruktor erstellen oder eine Methode, wo du speziell eine Rechnung aus der DB holst.

Aber mal praktisch: Eine Klasse ist wie gesagt allgemeingültig. Für die Spezialisierungen, nutzt du dann vererbte Klassen bzw. einfache Helfermethoden, die dir das eigentliche Objekt mit Daten füllen. CollectAllInvoices() bspw. füllt dir die Collection mit allen Rechnungen, CollectionInvoice( string ID ) füllt dir die Collection mit genau dieser einen Rechnung oder gibt dir evtl. ein spezielles Rechnungs-Objekt zurück.

 

[mosquito87]

Genau, es geht um C#.
Genauer: asp.net mit MVC. ;-)

Das Prinzip ist schon klar.
Das Befüllen auch.

Was mich etwas abschreckt:
Wenn es Kunden mit hunderten Rechnungen gibt, und ich auf einer Seite alle Kunden anzeigen will (sagen wir mal es sind 200 Kunden), dann hab ich 200 Objekte (der Klasse Kunde), die alle jeweils nochmal eine Collection haben, die voll mit Rechnungen ist.

Ist btw nur ein Beispiel.
Bei meiner Applikation geht es weder um Kunden, noch um Rechnungen.

 

[Daaron]

Du holst die Rechnungen erst bei Bedarf, nicht vorher.

 

[Yuuri]

Ja, dann ist das halt so. Wir dümpeln heutzutage ja auch nicht mehr mit 2 MB RAM herum und 30 MHz CPUs, die können das schon ab.

Das ERM dient ja auch eher der Modellierung der Datenbank. Wie du diese dann in Objekte kapselst, ist natürlich auch vom Datenbanklayout abhängig, kann aber natürlich auch gänzlich anders entwickelt werden. So es z.B. eben eine spezielle Klasse für einen Kunden mit einer Rechnung gibt bzw. du in die Klasse Rechnung die Kundendaten mit einbeziehst. Die Steuerung und das Füllen der Daten, würde ich immer über Methoden realisieren, sodass du dynamisch im Programmablauf auch wirklich nur die erforderlichen Daten befüllst.

Solche Übersichten sind aber auch kein Problem und Gang und Gebe im Geschäftsumfeld. Stell dir einen Shop mit 10.000 Produkten vor. Zu diesem gibt es Kategorien, Beschreibungen, Bilder und allen Pipapo. Ein Export dieser Daten (an bspw. Geizhals, Google Base, ...) kann hierbei gut und gern Zehn Minuten und mehr kosten.

Das reine Anzeigen solcher Übersichten im Browser, kannst du dabei ja nur aufs Wesentliche konzentrieren. Es sagt dir ja auch niemand, dass du Objekte immer komplett füllen musst, sondern in solchen Übersichten reichen ja eben nur die IDs und weitere kleine Beschreibungsfelder. Von den nun eigentlich vorhandenen Daten, zeigst du somit eben nur 1/5 an und reduzierst den Speicherverbrauch erheblich.

Aber wie oben geschrieben: Wir haben heut keine 2 MB RAM und 30 MHz CPUs mehr. Zudem wird solch eine Übersicht ja eh nur im Admin gelistet, wo genau gesehen nur ein paar Leute Zugriff darauf haben. Viel kannst du auch mit Caching einsparen.

 

[Ruheliebhaber]

Ich möchte noch mal 2 Punkte einwerfen.

1. Schau Dir das Entity Framework an! Dann kanst Du Dir eine Menge Arbeit sparen. Du modellierst einfach nur die gewünschten Daten in C#. Das ganze DB-Geraffel macht dann das Framework. Alternativ geht eventuell auch nHibernate.

2. Für Dein Performance-Problem gibt es auch eine Lösung. Entweder machst Du es so, wie vorgeschlagen (Collection aus IDs + Hilfsmethoden) oder Du schaust Dir einmal die Klasse "Lazy<T>" an. Es geht um verzögerte Initialisierung. Oder anders gesagt, Objekte werden erst dann erzeugt, wenn sie benötigt werden.

ASP.NET MVC schreit meiner Meinung nach übrigens geradezu nach einer RIA-Anwendung. Stichworte wie AJAX oder JQuery sollten also ebenfalls interessant sein.

 

[kuddlmuddl]

Wenn es Kunden mit hunderten Rechnungen gibt, und ich auf einer Seite alle Kunden anzeigen will (sagen wir mal es sind 200 Kunden), dann hab ich 200 Objekte (der Klasse Kunde), die alle jeweils nochmal eine Collection haben, die voll mit Rechnungen ist.

Dass die angezeigten Kunden-Ojekte jeweils Member haben die evtl. viel Speicherplatz benötigen ist doch irrelevant. Wenn du die Kundenobjekte anzeigst wird der ausführende Computer den Speicher der Member in keiner Weise verarbeiten - dh diese anhängenden Daten verlangsamen das ganze überhaupt nicht.
Wenns ne Collection ist die sowas wie .size() oder .length() unterstützt (ohne alle Rechnungen zu zählen) würde es nichtmal von Bedeutung sein wenn du bei der Kundenliste noch zusätzlich aufführst wie viele Rechnungen zu diesem Kunden gehören da der Wert ja nur eine Zahl ist.
Dh selbst wenn alle Rechnungen unkomprimiert als bmp gescannt den Kunden anhängen ist das vollkommen egal für ne Kundenübersichtsliste. Die Bilder liegen ja auf irgendeiner Platte und werden garnicht erst geladen - wozu auch.

 

[character]

Wenn du die Kundenobjekte anzeigst wird der ausführende Computer den Speicher der Member in keiner Weise verarbeiten

Das kommt auf die Implementierung an und genau das ist ja sein Problem.

Daaron hat es mit seinem kurzen Satz genau auf den Punkt gebracht: Die Daten sollten erst geladen werden, wenn sie auch wirklich gebraucht werden.

Beispiel (Pseudocode):

c = new Customer()    // Rechnungen noch nicht aus der DB laden
bills = c.getBills()  // erst jetzt wird die DB bemüht

Oder alternativ sowas mit spezieller Klasse:

bills = BillLoader.getBillsByCustomer(c)

Oder:

loader = new BillLoader(c)
bills = loader.getBills()

Oder auch direkt an der Bill-Klasse:

bills = Bill.getBillsByCustomer(c)

You get the idea. Das ist alles immer noch "100% objektorientiert" (wie du es so schoen ausgedrueckt hast), aber eben nach jeweils anderen Prinzipien und Patterns entworfen, die alle Vor- und Nachteile haben.

Die meisten ORMs sind da ziemlich flexibel und man kann eben dieses Verhalten einstellen.

 

[Fortatus]

Und nur so nebenbei: Objektorientierung ist nicht das Ende aller Weisheit. Wenn das Programm besser wird (schneller, ressourcensparender, leserlicher, besser wartbar, etc. pp.), indem du von solchen Paradigmen abweichst, dann ist das der richtige Weg.

 

[Daaron]

Wie kannst du nur solche ketzerischen Aussagen verbreiten, wo sich doch einige hier permanent darauf versteifen, dass nur 100% objektorientierte Sprachen überhaupt verwendet werden sollten...

 

[character]

Es nicht viele weit verbreitete Sprachen, die 100 % objektorientiert ist. Java gehört jedenfalls nicht dazu. JavaScript vermutlich schon, aber wegen der prototypischen Eigenschaften ist das sowieso etwas anders. C++ gehört nicht dazu, Python und Ruby auch nicht, etc. Smalltalk verwendet kein Mensch.

Falls du auf die Kritik an deiner Lieblingssprache PHP anspielst: Die liegt an PHPs allgemeiner Frickeligkeit, der Inkonsistenz, der Fehleranfälligkeit und der Schlampigkeit, Arroganz, Inkompetenz und Ignoranz der Maintainer, die sich sowohl im Sprachdesign als auch der Implementierung der Engine[1] widerspiegeln. Mit Objektorientierung an sich hat das nichts zu tun.

[1] Dabei kommt dann sowas raus...

 

[Dese]

Und nur so nebenbei: Objektorientierung ist nicht das Ende aller Weisheit. Wenn das Programm besser wird (schneller, ressourcensparender, leserlicher, besser wartbar, etc. pp.), indem du von solchen Paradigmen abweichst, dann ist das der richtige Weg.

ich würd eher sagen, dann hat man objektorienteirte programmierung noch lange nicht kapiert.
objektorientierte programmierung steht nicht einem einzigen der aufgezählten eigentschaften im weg. vor allem die letzten 2 sidn gerade die stärken von objektorientierte programmierung.

ich hab die rfahrung gemacht, dass wenn einer wenig ahnung hat objektorientiert zu programmieren, dann ist sein von diesem paradigma abweichender code noch schlimmer lessbar und wartbar als sein schlechter objektorietierter code.

edit: es gibt manchmal durchaus prakmatische gründe davon abzuweichen (skript sprachen die man verwenden "muss") oder performance gründe, wenn man sehr low level arbeiten muss. aber sonst?

 

[ice-breaker]

@character: Daaron hat keine Kritik an Sprachen geäußert sondern nur zu bedenken gegeben, dass es auch Wege ohne OOP gibt, die je nach Problematik besser geeignet sein könnten.

 

[character]

Ich weiss. Er kritisiert, dass Sprachen kritisiert werden, die nicht 100% objektorientiert sind. Damit meint er insbesondere die Kritik an PHP. Siehe andere Threads.

 

[Tumbleweed]

Ich lese hier recht viel mit, aber eine Kritik an mangelnder Objektorientierung ist mir noch nicht aufgefallen. Im Gegenteil - wirbt man für OOP kann man sich sicher sein, dass direkt einer darunter antwortet, dass OOP nicht das Maß aller Dinge ist.

Bei PHP wird wie schon erwähnt öfter mal darauf rumgehackt, dass es unsauber ist/erscheint, woraufhin mit an Sicherheit grenzender Wahrscheinlichkeit einer antwortet, dass man mit PHP auch sauber und objektorientiert programmieren kann und es sogar tolle Frameworks gibt.

@character: den Link fand ich sehr unterhaltsam.

 

[Dese]

ich bin hier beim mitlesen etwas neugierieg geworden bzgl. den vorwürfen zu php. vorweg: ich habe vor einigen jahren mal ein kleines projekt gemacht für einen kunden in php. das war das einzige und mal überhaupt.

was soll den an php so ausserordentlich schlimm sein?

in etwa gleicher menge habe ich erfahrungen mit asp und jsp machen können und in meiner kurzen und kleinen erfahrung in diesem bereich fand ich php um welten einfacher, intuitever und praktischer. nun, da diese erfahrungen zum einen paar jahre zurück liegen und auch vom unfang eher spärlich sind und nun hier so kommentare lese würde ich gerne mal etwas genaueres dazu hören.

vereinzelte macken und kuriositäten interessieren mich da nicht. so nen quatsch findet sich mal mehr mal weniger in allen sprachen, jeh neuer desto mehr. wenn also mir mal jemand objektiv und ohne persönliche übertreibungen mal erklären könnte was so schlimm an php seien soll, bzw. angeblich seien soll?

 

[character]

Hier ist eine relativ aktuelle Meinung dazu, aber das ist mittlerweile sehr off topic.

Der TE könnte mal antworten, ob ihm geholfen wurde oder ob es noch was zu klären gibt...

 

[Dese]

interessant. danke.

 

[mosquito87]

Vielen Dank für das Feedback.
Eine Grundsatzdiskussion wollte ich nicht auslösen.

Das Problem bei mir ist (in meinem System geht es nicht um Kunden und Artikel, war nur ein Beispiel), dass ich ein Benutzerobjekt nach dem Login in die Session des Users speichere. Dieses Objekt verfügt über diverse Collections, die die Implementierung von 1-zu-n Beziehungen zu anderen Entitäten darstellen.
In meinen Augen macht es wenig Sinn, diese direkt zu befüllen. Allerdings passiert das eigentlich auch nur 1x. Und dann wenn sich in den Entitäten etwas ändert.

Ich tendiere momentan wirklich dazu, die Beziehungen nicht objektorientiert darzustellen und den Inhalt der anderen Entitäten über den FK des Users laden, an den ich jederzeit über die Session rankomme.

Danke auch für den Vorschlag mit dem Entity Framework. Ich will momentan die DB Geschichte vor allem zu Lernzwecken selbst implementieren.
Das ist schon noch objektorientiert, allerdings sind die Beziehungen nicht mehr direkt implementiert.

 

[Ruheliebhaber]

Wenn Du alles in ein Objekt in der Session des Users steckst, gibt es eventuell Probleme.

1. Was ist, wenn das Benutzerobjekt sehr groß wird?

2. Was ist, wenn das System skaliert werden soll? MS nennt das eine Webfarm. Man kann das Hosting entweder über mehrere Server verteilen oder, jetzt kommt es, auf einem Server mit einem IIS auf mehrere Threads verteilen. Die Standardconfig des IIS ist "single threaded".
In beiden Fällen hast Du das Problem, daß die Session verloren geht, da bei jedem Request fröhlich Server und Threads gewechselt werden.
Eventuell wäre es eine Überlegung wert, alle Zustandsdaten einer Usersession sinnvoll in der DB abzulegen. Ich persönlich würde mein Benutzerobjekt serialisieren und in der DB speichern.