Laden...

Sind O/R-Mapper potentiell ein schleichender Tod?

Erstellt von Florian Reischl vor 14 Jahren Letzter Beitrag vor 14 Jahren 4.791 Views
Florian Reischl Themenstarter:in
1.564 Beiträge seit 2007
vor 14 Jahren
Sind O/R-Mapper potentiell ein schleichender Tod?

Hi %

Mich würde mal interessieren ob ich der einzige bin der sich manchmal wünschen würde, dass man O/R-Mapper in der IDE erst über eine Prüfung freispielen muss?

Versteht mich nicht falsch. Ich finde O/R-Mapper gut um einiges an Leichtsinnsfehlern zu vermeiden. Nichtsdestotrotz sind und bleiben es Tools wie andere. Vor dem verbreiteten Erscheinen von O/R-Mappern haben sich viele Entwickler, meiner Meinung nach, deutlich mehr Gedanken um das R in O/R gemacht. Das geht mit dem Datenbankdesign los - welches einfach nicht immer 1:1 auf eine Relationale Datenbank übertragen werden sollte - und endet mit falsch angewendetem Lazy-Loading. ... um jetzt nur zwei Punkte zu nennen.

Würde mich über eure Meinung freuen!

Grüße
Flo

Blog: Things about Software Architecture, .NET development and SQL Server
Twitter
Google+

Je mehr ich weiß, desto mehr weiß ich was ich noch nicht weiß.

6.911 Beiträge seit 2009
vor 14 Jahren

Hallo Flo,

A fool with a tool is still a tool.

Sagt eigentlich alles aus 😉 und deine Forderung könnte auch auf andere Bereiche ausgedehnt werden.

Speziell für O/R-Mapper sollten auch die Grundlagen einer Datenbank verstanden werden um diese richtig einzusetzen. Kenntnisse von SQL - geht eigentlich mit dem vorigen Punkt Hand in Hand - sind auch empfehlenswert.

Da diese Voraussetzung viele nicht erfüllen gibt es teilweise sehr "interessante" Klassen die unzulänglichen Entwurf wieder ausbügeln müssen.

Insofern kann ich deinen Wunsch nachvollziehen. Das wird jedoch nicht viel helfen denn anstatt die Prüfung abzulegen würden sicherlich andere Alternativen gefunden werden - mit ähnlichen Problemen 😉

mfG Gü

Stellt fachliche Fragen bitte im Forum, damit von den Antworten alle profitieren. Daher beantworte ich solche Fragen nicht per PM.

"Alle sagten, das geht nicht! Dann kam einer, der wusste das nicht - und hat's gemacht!"

Florian Reischl Themenstarter:in
1.564 Beiträge seit 2007
vor 14 Jahren

Hi Gü

A fool with a tool is still a tool.

War ist und bleibt für immer wahr. 😉

... würden sicherlich andere Alternativen gefunden werden - mit ähnlichen Problemen

Der Witz ist (für mich), dass die früher verbreiteten Probleme wie nicht parametrisierte Queries, SQL Injection, sonstige grundlegende SQL Fehler meiner Meinung nach durch O/R-Mapper recht gut abgefangen werden. Dafür werden heute Fehler gemacht die es früher nicht gab. Hat vielleicht damit zutun dass das Arbeiten mit O/R-Mappern einfach zu einfach erscheint. Früher ist mal jemand von seinem Platz aufgestanden und hat wen anders gefragt wenn es um ein Datenbankdesign, eine knifflige Abfrage oder was ähnliches ging.

Vielleicht gab es die Probleme früher auch nicht weil eine der einbezogenen Personen auf diese Probleme automatisch hingewiesen hat... Ist jetzt 'ne Theorie die mir gerade so in den Sinn kommt.

Grüße
Flo

Blog: Things about Software Architecture, .NET development and SQL Server
Twitter
Google+

Je mehr ich weiß, desto mehr weiß ich was ich noch nicht weiß.

49.485 Beiträge seit 2005
vor 14 Jahren

Hallo Florian Reischl,

mir ist nicht so ganz klar, worauf du hinaus willst. Es ist doch ein ganz normaler (Neben-)Effekt fast jeder technischen Entwicklung, dass die Lösung eines Problems neue und andere Probleme hervorruft. Die Frage ist, warum sollten da O/R-Mapper eine Ausnahme sein? Auch scheint es mir etwas weit hergeholt, aus den Problemen, die durch den technischen Fortschritt bei der Persistierung von Objekten hervorgerufen werden, nun gleich ein Untergangszenario ("schleichender Tod") zu konstruieren.

herbivore

Florian Reischl Themenstarter:in
1.564 Beiträge seit 2007
vor 14 Jahren

Hi herbivore

Ich will darauf hinaus, dass die Probleme von denen ich spreche auch schon vor dem Aufstieg der O/R-Mapper theoretisch existierten da die entsprechenden Gefahren (wie Lazy Loading) nicht erst mit O/R-Mappern aufkamen. Früher ist - meiner Meinung nach - jedoch bewusster mit dem Thema umgegangen worden.

Ich habe ja schon geschrieben, ich bin selbst ein Freund dieser Technologie, aber man sollte die Thematik unter dem Tool nicht vergessen. Wäre ungefähr so als würden wir alle verlernen zu laufen seit es Autos gibt (was oft durchaus zutrifft)

...gleich ein Untergangszenario ("schleichender Tod") zu konstruieren.

Die Formulierung habe ich bewusst gewählt 😉
Ich glaube manchmal muss man erstmal mit einer Aussage polarisieren/aufrütteln um ein gutes Ergebnis zu erzielen (was in diesem Fall diese Diskussion ist)

Grüße
Flo

Blog: Things about Software Architecture, .NET development and SQL Server
Twitter
Google+

Je mehr ich weiß, desto mehr weiß ich was ich noch nicht weiß.

49.485 Beiträge seit 2005
vor 14 Jahren

Hallo Florian Reischl,

Wäre ungefähr so als würden wir alle verlernen zu laufen

das ist m.E. zu einem gewissen Grad immer die Folge von Entwicklungen und Tools, die das Leben bequemer machen. Ein Tool ist ja dazu da, einem Arbeit abzunehmen und einen zu entlasten. Sicher wäre es oft wünschenswert, wenn die Benutzer eines Tools die internen Zusammenhänge besser verstehen würden und es nicht als BlackBox benutzen. Aber dieser Effekt wird eben immer bis zu einem gewissen Grad eintreten. Anderseits ist es durchaus gewünscht und hat auch positive Effekte, wenn man sich nicht mit den Internas rumschlagen muss. Information Hiding ist nicht umsonst ein wichtiger Punkt bei der Software-Entwicklung.

Ich glaube manchmal muss man erstmal mit einer Aussage polarisieren/aufrütteln um ein gutes Ergebnis zu erzielen

Ich kann dem Thema trotzdem nicht so viel abgewinnen. Was du beschreibt ist ein ganz normaler, bekannter und üblicher Effekt. Dazu gibts aus meiner Sicht nicht viel zu sagen. Außer, dass es eine unzutreffende Legende ist, dass Schüler (wozu ich jetzt mal die neuen Benutzer eines Tools zähle) von Generation zu Generation immer schlechter werden. Selbst im Mittelalter und sogar schon in der Antike wurde darüber geklagt, dass die Schüler immer schlechter würden und immer weniger verstünden. Nur wäre eine dauernde, signifikante Verschlechterung über solange Zeit nicht durchzuhalten, weshalb es eben auch nur eine Legende ist.

Mit anderen Worten: Die Welt wird auch die O/R-Mapper-Benutzer überleben, die weniger Kenntnisse über die Zusammenhänge haben, als die vorige Generation von Programmierern.

herbivore

PS: Passend zum allgemeinen Thema: Does Visual Studio Rot the Mind? von Charles Petzold.

Florian Reischl Themenstarter:in
1.564 Beiträge seit 2007
vor 14 Jahren

Hallo herbivore

Ich spreche ja gar nicht davon, dass "die Schüler schlechter werden" und will auch keinen Generations-Krieg beginnen. Ich sehe es bei mir in der Arbeit, dass selbst Entwickler der älteren Generation (>40) Fehler machen die sie früher nie gemacht hätten. Ich weiß, damit schließe ich meinen Wunsch nach dem "Prüfung" als Lösung aus, weil sie's theoretisch ja wissen.

Nichtsdestotrotz werden die Tools manchmal überschätzt/überfordert. Das wäre wie wenn jeder Dateien nur noch mit File.ReadAllText() verarbeiten würde oder man sagen würde "GUI Controls nur das könnten was der Designer" hergibt. (Die beiden Beispiele treffen es ganz gut.) Ich habe schon mehrfach (hier oder beim mir im Büro) Aussagen gehört wie "Das kann der Designer/Mapper (ist jetzt Platzhalter) nicht also geht's nicht"

Außerdem ist Datenbankdesign ja nicht das Ziel eines O/R-Mappers. Maximal die Erzeugung eines Basis-Schemas.

Die Tools sind gut und sollen verwendet werden, ich sehe nur oft dass sie schlicht durch eine schlechte Verwendung unter Beschuss geraten. Ich hatte letztens erst eine längere Diskussion in einem anderen Forum bei der NHibernat und ORMs im ganzen beschimpft wurden, am Ende hat sich rausgestellt dass die ganzen Probleme auf falscher Verwendung basierten.

ORMs nehmen viel Arbeit ab aber man sollte (wie beim Autofahren) den Kopf nicht ausschalten.

Grüße
Flo

Blog: Things about Software Architecture, .NET development and SQL Server
Twitter
Google+

Je mehr ich weiß, desto mehr weiß ich was ich noch nicht weiß.

2.187 Beiträge seit 2005
vor 14 Jahren

Hallo Florian Reischl,

Deine Argumente kann ich SEHR gut nachvollziehen. Das ist oft so, dass ein Tool verflucht wird, weil der Verwendet keine Ahnung hat, was es eigentlich tun soll.

O/R Mapper (wie alle anderen Hilfsmittel) haben einen allgemeinen Vorteil und einen allgemeinen Nachteil.
Vorteil: Das Wissen muss nicht mehr im Kopf des Anwenders sein.
Nachteil: Das Wissen muss nicht mehr im Kopf des Anwenders sein.
Es ist schön, dass jeder es Benutzen kann, nur schade, dass es so auch jeder falsch Benutzen kann.

Naja, jetzt hab ich tatsächlich einen schönen langen Post, der im endefeckt nichts neues sagt. 😄
Aber wenigstens zu deiner Aufmunterung: Du bist nicht der Erste der das so sieht und vermutlich auch nicht der Letzte und auch nicht alleine mit deiner Meinung.

Gruß
Juy Juka

Florian Reischl Themenstarter:in
1.564 Beiträge seit 2007
vor 14 Jahren

Hallo Juy Juka

Danke dir für deine Antwort!

Zu deiner Aussage "langer Post... nichts gesagt":
Kann man nicht sagen. Ich wollte ja explizit ein paar unterschiedliche Meinungen hören 😃

Grüße
Flo

Blog: Things about Software Architecture, .NET development and SQL Server
Twitter
Google+

Je mehr ich weiß, desto mehr weiß ich was ich noch nicht weiß.

S
469 Beiträge seit 2007
vor 14 Jahren

Dem stimme ich eigentlich auch vorsichtig zu (vorsichtig deshalb, weil ich mich mit OR Mappern nur theoretisch auskenne und noch nie einen benutzt hab).
Einem Anwender ohne viel (im Extremfall vielleicht sogar ganz ohne) Kenntnisse über DB-Design wird durch das Tool vorgegaukelt, er könne einfach so ne Datenbank erstellen und gut is. Meiner Meinung nach sollten hier die Verantwortungen klar aufgeteilt werden, jemand der sich mit DB auskennt sollte sich um diese Seite kümmern, und um "den Rest" dann "ein anderer".
Ich beschäftige mich ja auch mit Datenbanken, aber ich mache immer zuerst die Datenbank, genauso, wie es die Vorgaben erfordern. Erst dann kommt der Code dran.
So komme ich auch garnicht in die Versuchung, die Datenbank so zu machen, dass mein Code einfacher wird. So was habe ich leider schon öfters gesehen 😦, und wenn dann noch das Argument kommt, ja hat das Tool so ausgegeben wird schon stimmen, sich die Leute also scheinbar blind auf ein Tool verlassen...grummel.

sth_Weird

++++++++++++++++++++~+
Fluchen ist die einzige Sprache, die jeder Programmierer perfekt beherrscht


Linux is for free...if your time is worth nothing
++++++++++++++++++++~+

Florian Reischl Themenstarter:in
1.564 Beiträge seit 2007
vor 14 Jahren

Hi sth_Weird

Danke dir für deine Antwort.

Ich fange nicht zwingend mit der Datenbank an wenn ich ein neues Projekt (oder ein neue Feature) aufbaue. Ich fange oft (meistens) mit dem Domain-Model an. Es muss nur klar sein, dass das Domain-Model nicht (zwingend) was mit dem Datenbank-Model zutun haben muss.

Der Designer der Datenbank sollte halt auch wissen was eine Datenbank ist und wie sie tickt (das kann sich sogar von DBMS zu DBMS sehr unterschiedlich verhalten). Datenbankdesign ist einfach ein Thema das auf Erfahrung basiert. Viele Verwender von O/R-Mappern vergessen das leider oft und das halt zu massiven Problemen führen.

Schön zu sehen, dass ich mit meiner Meinung nicht alleine stehe. 🙂

Grüße
Flo

Blog: Things about Software Architecture, .NET development and SQL Server
Twitter
Google+

Je mehr ich weiß, desto mehr weiß ich was ich noch nicht weiß.

X
1.177 Beiträge seit 2006
vor 14 Jahren

huhu,

Ich weis nicht so recht. Ich bring mal ein anderes Beispiel und versuch dann den Bogen wieder zurück zum O/R-Mapper zu schlagen: Früher konnte ich mir jede Telefonnummer merken. Wirklich jede. Dann hab ich mir doch ein Handy zugelegt. Nachdem es da das schöne interne Telefonbuch gibt, hat mein Hirn vergessen wie man sich Telefonnummern merkt. Oder: Navis - man, früher konnten alle (naja zumindestens viele) eine Karte lesen bzw. sich den gefahrenen Weg merken. Heute muss man ja fast schon froh sein, wenn ein Navi-Benutzer nicht versehentlich in einen See fährt^^

Aber: Nur weil mein Großvater Schweine geschlachtet hat, ist es für mich nicht notwendig dieses Wissen auch zu haben. Mein Vater weigert sich ja sogar schon einen Computer einzusetzten (wobei der sogar schneller im Kopf rechnet als ich mit nem Taschenrechner) - soviel zu "die jüngeren wissen immer weniger". Die Anwendungsgebiete ändern sich. Die Voraussetzungen sind andere und der Mensch ist so flexibel, dass er sich mit neuen Routinen im Hirn darauf einstellt. Dabei rutschen eben alte, jetzt nicht mehr benötigte "Routinen" in den Hintergrund (-> Programmierer die es besser wissen müssten).

Ich denke nicht, dass es ein "schleichender Tod" ist. Eher eine Art Evolution. Früher setzte man einfach eine DBase-DB ein und gut. Heute kann man vom SQL-Server erfahren wie oft er sich wünscht, dass da ein Index auf einer Tabelle liegen würde. Könnte es nicht passieren, dass die Evolution weitergeht, und die O/R-Mapper in Zukunft sowas sogar selbst auswerten und entsprechende Optimierungen anbieten/vornehmen?

Ein zusätzlicher Faktor, den es auch immer mal wieder in der Menschheitsgeschichte gab: Spezialisierung auf Aufgaben. Vor einiger Zeit mussten Programmierer noch "breit gefächert" arbeiten, jetzt dürfen einzelne den ganzen Datenbank-Kram vergessen, andere erleiden den schleichenden Tod in Punkten wie Usability von Frontends, nur weil sie immer mehr nur noch mit Datenbanken arbeiten.

Die Entwicklung an sich ist für mich einfach nachvollziehbar und gut so. Wenn jetzt eben ein schlechtes Datenbank-Design herauskommt, weil ein Programmierer nur noch mit einem O/R-Mapper rumhantiert, dann ist das doch im Gegenzug eigentlich das Problem, dass zu geeigneter Zeit der DB-Spezialist nicht die Finger drauf hatte. Vielleicht eher ein Kommunikations-Problem oder Kompetenz-Gerangel in der Mannschaft (dies ist z.B. bei uns der Fall)

Es betrifft übrigens nicht nur O/R-Mapper, sondern irgendwie fast alle Punkte in einem Softwareprojekt. Ich denke, wir Programmierer müssen da noch einiges lernen was z.B. auf dem Bau ja selbstverständlichste Arbeitsteilung ist. Nur kann man bis jetzt die Grenzen in der Arbeitsteilung nicht so exakt ziehen wie zwischen Maurer und Elektriker.

😃

Xynratron

Herr, schmeiss Hirn vom Himmel - Autsch!

Die Erfahrung zeigt immer wieder, dass viele Probleme sich in Luft auslösen, wenn man sich den nötigen Abstand bzw. Schlaf gönnt.

Florian Reischl Themenstarter:in
1.564 Beiträge seit 2007
vor 14 Jahren

Hi Xynratron!

Heute kann man vom SQL-Server erfahren wie oft er sich wünscht, dass da ein Index auf einer Tabelle liegen würde. Könnte es nicht passieren, dass die Evolution weitergeht, und die O/R-Mapper in Zukunft sowas sogar selbst auswerten und entsprechende Optimierungen anbieten/vornehmen?

Wenn das mal passiert dürfte der Weg dahin aber noch lang sein. Die Missing-Index-Vorschläge von SQL Server sind noch nicht ganz optimal, hier übertreibt er an manchen Stellen. Außerdem beeinträchtigt die Generierung eines Index ja massiv die Performance des laufenden Systems. Nur in der Enterprise Edition ist es möglich einen Index wirklich ONLINE zu erzeugen und die hat ja ihren Preis.

Ein zusätzlicher Faktor, den es auch immer mal wieder in der Menschheitsgeschichte gab: Spezialisierung auf Aufgaben.

Wenn das bei euch so ist (auch wenn's nicht 100% funktioniert) beglückwünsche ich dich. Hier kommt es mir eher umgekehrt vor. Früher hat man zum Thema Datenbank noch bestimmte Leute gefragt, heute meint hier irgendwie jeder, dass er/sie eine Datenbank designen können. Geht halt schick über die Oberfläche vom ORM (der dann natürlich 1:1 die Objekt-Struktur auf die Datenbank steckt) und Leute die fast nur Web-Seiten entwickeln erstellen Datenbanken.

Wenn jetzt eben ein schlechtes Datenbank-Design herauskommt, weil ein Programmierer nur noch mit einem O/R-Mapper rumhantiert, dann ist das doch im Gegenzug eigentlich das Problem, dass zu geeigneter Zeit der DB-Spezialist nicht die Finger drauf hatte.

Wie schon gesagt. "Der DB-Spezialist" ist hier durch "den O/R-Mapper" und "den Designer vom ORM" ersetzt worden. Ich weiß nicht ob wir damit alleine stehen oder ob das weitläufig so ist.

Grüße
Flo

Blog: Things about Software Architecture, .NET development and SQL Server
Twitter
Google+

Je mehr ich weiß, desto mehr weiß ich was ich noch nicht weiß.

S
401 Beiträge seit 2008
vor 14 Jahren

Hallo Florian,

dein Anliegen ist mir klar und stimme dir zu.

Der Designer der Datenbank sollte halt auch wissen was eine Datenbank ist und wie sie tickt (das kann sich sogar von DBMS zu DBMS sehr unterschiedlich verhalten). Datenbankdesign ist einfach ein Thema das auf Erfahrung basiert. Viele Verwender von O/R-Mappern vergessen das leider oft und das halt zu massiven Problemen führen.

Der Grundgedanke hinter eines O/R-Mapper ist doch, eine Objekt-Orientierte-Anbindung zu Datenbank zu schaffen. Die Anbindung soll unabhängig von der DB sein.

Somit muss der O/R-Mapper die DB spezifischen Einstellungen und Optimierungen dem Programmierer abnehmen. Dieser weiß theoretisch nichts von der Zieldatenbank. Genau hier ist das Problem. Es wird einfach zu wenig Zeit in die Entwicklung von O/R-Mapper investiert! Weshalb das Problem bestehen bleibt. Mir kommt es so vor, als wäre ein O/R-Mapper ein billiges und einfaches Tool, dass man besitzen muss. Aber dem ist nicht so 😜

Es muss noch viel Gehirnschmalz in die Entwicklung gesteckt werden.
Hibernate (kenne ich nur aus Java) bietet zum Beispiel die Möglichkeit, die Abbildung auf der Datenbank zu steuern und anzupassen. Sprich, es muss das Modell nicht 1:1 auf die Datenbank übertragen werden. Für jede DB eine Config-Datei (*.xml) manuell schreiben und gut ist es.

Gruß,
Thomas Enzinger

X
1.177 Beiträge seit 2006
vor 14 Jahren

huhu,

Kann das sein, dass Du Dich über ein "echt gelungenes" DB-Design "freust"? ^^ Da bist Du nicht alleine. Ich freue mich z.B. relativ oft über php-Programmierer - aber das wäre ja schon wieder so ein Kapitel.

Ich meinte übrigens wirklich sowas wie "Evolution" - auch die missing Index vom SQL-Server werden besser werden. Die OR-Mapper weren besser werden.

Ich glaube wirklich, dass allein aufgrund dass es solche Tools gibt, die auf einem bestimmten Gebiet weniger bewanderten Programmierer sich da trozdem rantrauen. ("Kann ja nicht so schwer sein" - genau wie so mancher Heimwerker denkt er wäre ein Zimmermann) Aber ich denke, diese Entwicklung wird sich wieder umkehren. Spätestens dann, wenn man mal mit einem Projekt so richtig auf die Nase gefallen ist und sich entschliesst einen Spezialisten zu fragen. (Obwohl, wann lernt der Mensch eigentlich wirklich aus seinen Fehlern?)

Naja, anders gesagt: Ich glaube nicht, dass die Tools welche wir einsetzen dafür verantwortlich sind dass die Qualität der erzeugten Software sinkt. Für mich ist es eher eine Mischung aus mehreren Faktoren. Z.B. bemerke ich, dass es nicht mehr wirklich viele junge Leute gibt, die mit richtig Herzblut bei der IT sind - für die ist das ein Beruf wie jeder andere geworden. Genauso wie viele "alte" auf ihrer eingefahrenen Schiene hängen bleiben und wenn sie sich dann wirklich mal auf was neues einlassen (z.B. O/R-Mapper) dann wird es zum Allheilmittel.

😃

Xynratron

Herr, schmeiss Hirn vom Himmel - Autsch!

Die Erfahrung zeigt immer wieder, dass viele Probleme sich in Luft auslösen, wenn man sich den nötigen Abstand bzw. Schlaf gönnt.

3.511 Beiträge seit 2005
vor 14 Jahren

Früher hat man zum Thema Datenbank noch bestimmte Leute gefragt, heute meint hier irgendwie jeder, dass er/sie eine Datenbank designen können.

Danke. Den Satz müsste ich auf DIN A1 ausdrucken und an die Hauswand hängen 😃

Bei z.B. O/R Mappern die aus den Objekten das DB Schema erstellen, sehe ich extreme Gefahren. Viele Leute "denken", das sie nur noch gegen Objekte arbeiten und nicht mehr bewusst sind, das da doch noch ein vollwertiger z.B. SQL Server hinterhängt. Dann kommt es zu Situationen, das hier und da mal "schnell" neue Properties angelegt werden und funktioniert ja dann. Naja, spätestens, wenn die Performance irgendwann in Keller geht, sollte man wissen warum.

Ich selber setze auch O/R Mapper ein. Allerdings nur bei kleineren Projekten (z.B. kleine (Konfigurations-)Tools). Bei Enterprise Lösungen (n-Tier) bin ich momentan weg von O/R Mappern. Wobei ich mir demnächst ganz intensiv das EF 2.0 anschauen will, da es für n-Tier wohl einige gute Möglichkeiten bietet.

Ich stehe O/R Mappern an sich skeptisch gegenüber. Auf der einen Seite erleichtern die Mapper die Arbeit teils enorm. Auf der anderen Seite "vergisst" man wie eine Datenbank funktioniert und vorallem, wie man SQL schreibt. Bei manuellen arbeiten (über SqlConnection & Co) habe ich jedes Zeichen im SQL Script im Griff. Ich kann gezielt Stellen optimieren. Was ich bei einem O/R Mapper gar nicht, oder nur bedingt machen kann. In meiner alten Firma haben wir teils über Wochen nur an DB-Designs und SQL Statements gearbeitet und mehr nicht. Sowas vermisse ich irgendwie.

Die Anbindung soll unabhängig von der DB sein.

Das z.B. habe ich noch nie als Argument für einen O/R Mapper genutzt. Ich z.B. arbeite zu 99% gegen den SQL Server. Trotzdem setzte ich die Dinger ein, da es einen die Arbeit enorm erleichtern kann.

Kann das sein, dass Du Dich über ein "echt gelungenes" DB-Design "freust"?

Darüber freue ich mich allerdings auch jedesmal 😃

"Jedes Ding hat drei Seiten, eine positive, eine negative und eine komische." (Karl Valentin)

Florian Reischl Themenstarter:in
1.564 Beiträge seit 2007
vor 14 Jahren

Servus Siassei

Der Grundgedanke hinter eines O/R-Mapper ist doch, eine Objekt-Orientierte-Anbindung zu Datenbank zu schaffen. Die Anbindung soll unabhängig von der DB sein.

Sehr richtig. In kleinen Projekten kann es ja durchaus sinnvoll sein (weil weniger Aufwand) wirklich ein 1:1 Mapping zu haben. Darum existieren Mapper wie LINQ2SQL oder Castle-ActiveRecord. In einem komplexen Domain-Model kann das aber zum echten Problem werden.

...Es wird einfach zu wenig Zeit in die Entwicklung von O/R-Mapper investiert! Weshalb das Problem bestehen bleibt. Mir kommt es so vor, als wäre ein O/R-Mapper ein billiges und einfaches Tool, dass man besitzen muss. Aber dem ist nicht so 😛

Ich glaube an der Stelle bin ich jetzt (aufgrund persönlicher Erfahrung) anderer Meinung 😁 . Bei uns wird viel zu viel Zeit in den ORM investiert um ihn immer mehr zur eierlegenden Wolmilchsau zu machen. Weil viel zu viele Sonderfälle direkt in den OR-Controller gepackt wurden statt sie einfach in einem einzelnen Projekt spezifisch zu handeln strotzt das Ding derzeit von mehr als 200(!!) Methoden die kein Mensch mehr versteht.

Ich finde ein ORM sollte solide 90-95% abfackeln können. Alles darüberhinaus ist so speziell dass es - meiner Meinung nach - mehr Sinn macht eine Speziallösung darüberzustecken. Ein guter ORM zeichnet sich für mich dadurch aus die Möglichkeit zu bieten ihn (z.B. durch spezielle SQL Lösungen) zu erweitern. Das sind (und sollen bleiben) natürlich Sonderfälle aber die sind manchmal wichtig. Wenn das dann bedeutet, dass man diese Speziallösung für ein anderes DBMS portieren muss kann's das trotzdem wert sein.

Hibernate (kenne ich nur aus Java) bietet zum Beispiel die Möglichkeit, die Abbildung auf der Datenbank zu steuern und anzupassen. Sprich, es muss das Modell nicht 1:1 auf die Datenbank übertragen werden. Für jede DB eine Config-Datei (*.xml) manuell schreiben und gut ist es.

Falls du's mal brauchst, können NHibernate und EF (besser in V2) auch.

Danke dir für dein Feedback
Flo

Blog: Things about Software Architecture, .NET development and SQL Server
Twitter
Google+

Je mehr ich weiß, desto mehr weiß ich was ich noch nicht weiß.

Florian Reischl Themenstarter:in
1.564 Beiträge seit 2007
vor 14 Jahren

Hi Xynratron

Ich glaube wirklich, dass allein aufgrund dass es solche Tools gibt, die auf einem bestimmten Gebiet weniger bewanderten Programmierer sich da trozdem rantrauen. ("Kann ja nicht so schwer sein" - genau wie so mancher Heimwerker denkt er wäre ein Zimmermann)

Zum rantasten ist das auch total okay. Speziell im Privatgebrauch oder wirklich keinen Projekten sind ORMs eine tolle Hilfe eine Lösung zu bekommen ohne einen Dunst von der Materie zu haben. Wenn man in größeren Projekten jedoch eine komplexe Technologie wie Datenbanken einsetzen will finde ich sollte man wissen (oder wissen wen man Fragen kann) wie so ein Monster tickt. Ich arbeite jetzt seit ca. 15 Jahren mit SQL Server und lerne bis heute immer wieder neue Eigenheiten kennen.

(BTW: Natürlich kann ich heimwerken wie ein gelernter Zimmermann! 😄 )

Aber ich denke, diese Entwicklung wird sich wieder umkehren. Spätestens dann, wenn man mal mit einem Projekt so richtig auf die Nase gefallen ist und sich entschliesst einen Spezialisten zu fragen. (Obwohl, wann lernt der Mensch eigentlich wirklich aus seinen Fehlern?)

Ich weiß nicht auf wie viele Menschen das zutrifft. Wir haben zwar alle durch hinfallen das Laufen gelernt. Sich nach Fehlern selbst reflektieren und zu überlegen was man selber falsch gemacht hat ist eine Eigenschaft die ich leider nicht sehr vielen Leuten zuschreiben würde.

...Z.B. bemerke ich, dass es nicht mehr wirklich viele junge Leute gibt, die mit richtig Herzblut bei der IT sind - für die ist das ein Beruf wie jeder andere geworden.

Da kann ich jetzt glücklicherweise das Gegenteil bei mir im Büro berichten. Mein Ex-Azubi war/ist wirklich an der ganzen Sache interessiert und beschäftigt sich wesentlich mehr mit der Materie (auch mit Themen die er erstmal vielleicht nicht braucht) als er müsste.

Viele Grüße
Flo

Blog: Things about Software Architecture, .NET development and SQL Server
Twitter
Google+

Je mehr ich weiß, desto mehr weiß ich was ich noch nicht weiß.

Florian Reischl Themenstarter:in
1.564 Beiträge seit 2007
vor 14 Jahren

Hi Khalid

Früher hat man zum Thema Datenbank noch bestimmte Leute gefragt, heute meint hier irgendwie jeder, dass er/sie eine Datenbank designen können.
Danke. Den Satz müsste ich auf DIN A1 ausdrucken und an die Hauswand hängen 🙂

😁 😁 😁

Ich selber setze auch O/R Mapper ein. Allerdings nur bei kleineren Projekten (z.B. kleine (Konfigurations-)Tools). Bei Enterprise Lösungen (n-Tier) bin ich momentan weg von O/R Mappern.

Ich muss gestehen ich bin auch immer noch hin und her gerissen. Einerseits finde ich die Tools gut und empfehle sie auch - gerne - weiter, anderseits habe ich noch keinen gefunden der wirklich alle Wünsche erfüllt. Damit meine ich jetzt nicht alle Abfragen handeln können sondern die nötige Transparenz und Flexibilität bietet.

Wir arbeiten im Büro zwar exklusiv mit einem O/R-Monster (weil vorgeschrieben) das bringt aber oft viele Probleme die man ohne das Ding eigentlich wesentlich besser lösen könnte. (Ladezeit des Controllers > 2 Sekunden, deutlich mehr als 30MB Speicherverbrauch OHNE das irgendwelche Daten geladen sind, keine PI, ...)

Ich habe mir die letzten Tage mal die DSL Tools für VS2008 genauer angeschaut und muss gestehen dass mir ein ordentliches Modellierungstool und ein paar Transformationen mit ein Hilfsklassen mindestens(!) genauso hilfreich erscheinen. (Überlege zur Zeit ob ich vielleicht einen Artikel dazu schreiben soll.) In VS2010 werden die Features zur Modellierung ja noch ungleich mächtiger.

Wobei ich mir demnächst ganz intensiv das EF 2.0 anschauen will, da es für n-Tier wohl einige gute Möglichkeiten bietet.

Ist ein Thema das auch noch auf meiner Todo-Liste steht. Was ich bislang mitbekomme bietet's viele schicke (und hilfreiche) neue Möglichkeiten, muss man aber mal genauer anschauen.

... Ich kann gezielt Stellen optimieren. Was ich bei einem O/R Mapper gar nicht, oder nur bedingt machen kann.

Eben das fehlt mir irgendwie bei allen ORMs aktuell auch.

In meiner alten Firma haben wir teils über Wochen nur an DB-Designs und SQL Statements gearbeitet und mehr nicht. Sowas vermisse ich irgendwie.

*seufz*

Grüße
Flo

Blog: Things about Software Architecture, .NET development and SQL Server
Twitter
Google+

Je mehr ich weiß, desto mehr weiß ich was ich noch nicht weiß.