Laden...

Datenbankanwendungen in der Realität?!?

Erstellt von Fracoon vor 16 Jahren Letzter Beitrag vor 16 Jahren 3.944 Views
F
Fracoon Themenstarter:in
85 Beiträge seit 2007
vor 16 Jahren
Datenbankanwendungen in der Realität?!?

verwendetes Datenbanksystem: Postgres

Hallo an alle Profis,

ich bin etwas verwirrt was Datenbankzugriffe angeht, und wollte mal fragen wie es in der Programmierwelt so aussieht.

Hab mich schon etwas mit Postgres und Npgsql auseinandergesetzt und auch schon ein Paar kleine Programme geschrieben die Datenbanken auslesen und beschreiben können. Mit Connections, Dataadapter, Datatable bzw Dataset und Bindung an die GUI.

Hab jetzt schon des öffteren von O/R Mappern gelesen und wenn ich es richtig verstehe wird durch einen O/R Mapper die Datenbankstruktur in Klassen abgebildet. Und wenn ich weiter richtig verstehe macht ein O/R Mapper einem die Arbeit einfach nur leichter?!? Mann könnte ja in einem Programm das O/R Mapping auch selbst in die Hand nehmen?!?

Hab auch nach EINIGEN startschwierigkeiten NHibernate mit dem Beispielprojekt aus der Doku ans laufen gebracht. Muss aber ehlrich sagen das mir NHibernate überhaupt nicht gefällt weil ich keine wirklich gute Doku gefunden hab. Oder hab ich nur falsch gesucht?!

Gibt es etwas vergleichbares wie NHibernate für .Net? Etwas zu dem viele Tutorials/Howtos/Doku vorhanden ist?

Was mich auch schon lange beschäftigt : Ist es Praktikabel auch für größere Projekte mit vielen Clients die Datenbank direkt anzusprechen? Oder nimmt man dann ne eigene Serveranwendung die das O/R-Mapping übernimmt?

Naja ich glaub ich lass mal gut sein jetzt. Hab die Befürchtung dass wenn ich zu viel schreibe sich niemand mehr die Zeit nimmt alles zu lesen =)

Vieleicht will ja jemand mal seinen qualifizierten Senf dazu abgeben ^^. Würd mich freuen.

2.187 Beiträge seit 2005
vor 16 Jahren

Hallo Fracoon,

Ein O/R Mapper macht einem die Arbeit einfacher ja und bringt noch folgende Vorteile:
Abstraktion
Man muss nicht mehr wissen, woher die Objekte kommen. Die Datenquelle wird verscheiert. So liese sich (theoretisch) ohne Code-Änderung in der Business-Logik von FatClient- auf n-Tier-Architektur umschalten oder von Datenbanken auf Serialisierte Objekte oder ...

Kapselung
Der Zugriff auf die Datenquelle wird versteckt, da durch muss man nicht mehr alle Details des Datenzugriffs können und kann sich besser auf die "business"-Probleme konzentrieren.

Zentralisierung
Ein O/R Mapper sorgt dafür, dass aller Zugriffe über eine Zentralle Stelle laufen und somit besser kontrolliert und vor allem besser gewartet werden können!

Objekte
Wenn man Objekte hat, kann man alle erprobten und von Spezialisten (z.B.: GOF) entwickelten Verfahren anwenden.

Wie man die Architektur eine "große" Anwendung aufbaut ist von vielen Faktoren abhänig (Sicherheit, Geschwindigkeit, Netzwerkstruktur, ...). Eigentlich unzählige Faktoren. Mehr kann ich leider auch nicht sagen, da ich noch keine "große" Anwendung entworfen/entwickelt habe.

Gruß
Juy Juka

3.728 Beiträge seit 2005
vor 16 Jahren
Ado.net

Hallo Fracoon,

ob man OR-Mapping überhaupt einsetzt, oder nicht, ist am Ende Geschmacksache. NHibernate gehört sicher zu den populärsten Vertretern. Nur weil viele Leute gerne mit benutzerdefinierten Objekten als Datencontainer arbeiten, heißt das nicht, dass Du es auch so machen musst. Ich finde z.B. nicht, dass NHibernate irgendwas einfacher machen würde. Stattdessen muss man irgendwelche XML-Mapping-Konfigurationsdateien erstellen und eine properitäre Abfragesynatx erlernen. Ich behaupte sogar ganz ketzerisch, die Java-Leute schwören nur deshalb auf OR-Mapping, weil sie kein ADO.NET haben 8). Da Java an Universitäten und Hochschulen wesentlich weiter verbreitet ist als C#, sind die Java-Konzepte - von denen manche wirklich wahre Perlen sind - natürlich viel bekannter und schwingen noch mit einem Hauch Plattformunabhängigkeit nach. Die Technologieen portiert man dann in J# oder C# und setzt vor den Namen ein N für .NET. Dann freuen sich alle und manche haben Probleme, die sie ohne die portierten Technologieen gar nicht hätten. Aber das ist nur meine persönliche Theorie, die ich nicht beweisen kann und der nicht zuviel Bedeutung zuzumessen ist.

Wenn Du mit den ADO.NET-Bordmitteln (Connections, Commands, DataAdapter, DataTables, DataSets, Typisierte DataSets) gut zurecht kommst und damit bereits gute Erfahrungen gemacht hast, gibt es eigentlich keinen Grund, einen OR-Mapper einzusetzen. Wenn Du damit nicht zufrieden warst, such Dir einen schönen OR-Mapper aus. Es gibt noch andere OR-Mapper. Du kannst Dir mit ein bisschen Reflection, ADO.NET-Commands und einem DataReader auch mit ein paar Handgriffen einen eigenen OR-Mapper bauen. Natürlich sollte man sich vorher fragen, ob die Welt einen weiteren OR-Mapper wirklich braucht.

Bei den vielen Diskussionen wird oft vergessen, dass es nur um den Datenzugriff geht. Am Ende werden in den meisten Fällen SELECT-, INSERT-, UPDATE- und DELETE-SQL-Anweisungen erzeugt und ausgeführt. Über wie viele Schichten, Mapper, Komponenten oder sonstige "Umwege" man das tut, ist deshalb wirklich nur eine Frage der eigenen Vorliebe. Ein Objekt-Fetischist wird niemals ADO.NET einsetzen und ein Datenbankmensch, der mit ADO groß geworden ist, wird lieber ADO.NET einsetzen, als einen OR-Mapper, der versucht den SQL-Code vor dem Entwickler zu verstecken. Entscheide Dich einfach für die Seite, bei der Du Dich am wohlsten fühlst. Alles hat Vor- und Nachteile.

Gruß

Rainbird

2.187 Beiträge seit 2005
vor 16 Jahren

... Objekt-Fetischist ...

*Meld*

G
497 Beiträge seit 2006
vor 16 Jahren

ich persönlich möchte die Datenbankunabhängigkeit und die Möglichkeiten, die mir NHibernate im Zusammenspiel mit vernünftig ausgestalteten Objektklassen bietet, nicht missen.

3.511 Beiträge seit 2005
vor 16 Jahren

Also, ich kann JuyJuka an sich nur zustimmen. O/R Mapper machen IMHO die Arbeit um einiges einfacher. Das ist u.a. der Grund, warum ich bei Fragen zu DataTables und DataSets meistens nur die Schultern zucke, weil ich damit nie arbeite 🙂

Gibt es etwas vergleichbares wie NHibernate für .Net? Etwas zu dem viele Tutorials/Howtos/Doku vorhanden ist?

Wenn du das Framework 3.5 anpeilst, schau dir das ADO.Net Entity Framework an. Das ist ziemlich mächtig. Wenn du das FW 2.0/3.0 anpeilst, dann schau dir XPO von DevExpress an. Das Teil kostet zwar etwas Geld, aber ist verdammt gut. Zu beiden gibt es eine Menge an Beispielen und Tutorials.
Sicherlich gibt es noch unzählig weitere Alternativen, wie z.B. Regina.NET. Oder frag doch mal JuyJuka 😉

... Objekt-Fetischist ...

*Melded sich ebenfalls*

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

M
110 Beiträge seit 2007
vor 16 Jahren

Eine schöne Liste über O/R Mapper gibt es bei Wikipedia (englisch)

Gruss

Mirko

Mappen statt hacken mit Invist , dem .NET O/R Mapper - Code Generator

S
8.746 Beiträge seit 2005
vor 16 Jahren

Ich denke, es kommt immer darauf an, was man macht. ADO.NET bietet sich m.E. an, wenn man primär view-orientiert und lesend auf die Daten zugreift. Dann ist es schnell und elegant. Beim Schreiben, insbesondere wenn Relationen im Spiel sind, kriege ich ganz schnell Nervenkrebs mit ADO.NET und verfluche mich selbst, warum ich keinen O/R-Mapper genommen hab.

Und: Je mehr die Daten aus der DB einer komplexen Weiterverarbeitung unterliegen, desto eher macht OO Sinn. Und je mehr OO, desto eher fliegt ADO.NET aus dem Rennen (weil es keinen Millimeter OO ist, außer dass die Funktionalität in Klassen vorliegt). Wenn hingegen die Daten direkt an ein UI gehen, editiert oder ergänzt und dann fast ohne Bearbeitung persistiert werden soll (Produktdatenbank, o.ä.) je eher macht ADO.NET Sinn. Anders formuliert: Bildet das OO-Modell die Daten aus DB ab (dann ADO.NET) oder ist die DB nur die persistierte Form der Objekte (dann O/R)?

Ich persönlich bin kein Freund von NHibernate, weil mir die Tools, Wizards und Designer fehlen, die das ganze erst produktiv machen. Es ist ok, wenn man XML zur Konfiguration hat, aber zu 99% will ich damit nix zu tun haben. Wirklich notwendig finde ich ein externes Mapping nicht. Man spielt selten dessen Vorteile aus, aber der Code ist immer verteilt. Attributierung im Code ist mir eigentlich lieber.

Es gibt aber einige kommerzielle Tools, die sehr gute Arbeit machen und eine deutlich bessere Produktivität bieten. Kosten meist nur ein paar Hundert Euronen. Seien mal LLBlGen Pro und Open Access genannt.

Man sollte O/R-Mapper inbesondere dann in Betracht ziehen, wenn die DB noch nicht existiert. Bestehende Alt-DBs, womöglich mit schlechtem Design, nachträglich via O/R auf ein grausames OO-Modell abzubilden macht keine Freude.

LINQ to SQL ist eine schöne Sache, aber ehrlicherweise den Profi-O/R-Mappern _noch _unterlegen, unterstützt z.B. Vererbung nicht ausreichend. Schön sind O/R-Mapper die _auch _LINQ (to XYZ) unterstützen. Gilt noch auch für das Entity Framework.

F
10.010 Beiträge seit 2004
vor 16 Jahren

Schonmal ActiveRecord vom CastleProject und dessen ActiveWriter angeschaut?

ActiveRecord setzt auf NHibernate auf, implementiert aber das Activerecord-Pattern (ach 😉

Und mit ActiveWriter hast Du das zugehörige DSL Tool, um das dann zu Modellieren.

S
8.746 Beiträge seit 2005
vor 16 Jahren

Ja, hab ich. Allerdings stört mich hier die Verwendung einer Basisklasse erheblich. Da gefällt mir der IL-Enhancement-Ansatz von Open Access schon besser.

F
10.010 Beiträge seit 2004
vor 16 Jahren

Ich bin mir sicher, das man das mit LinFu recht einfach nachgebaut bekommt 😉

476 Beiträge seit 2004
vor 16 Jahren

hallo,

Ich behaupte sogar ganz ketzerisch, die Java-Leute schwören nur deshalb auf OR-Mapping, weil sie kein ADO.NET haben 8).

ich war so frei und habe Java-Entwickler mit dieser These konfrontiert und siehe da, diese haben das sogar zähneknirschend zugegeben.

Anders formuliert: Bildet das OO-Modell die Daten aus DB ab (dann ADO.NET) oder ist die DB nur die persistierte Form der Objekte (dann O/R)?

in der Praxis bin ich auch kein Freund von OR-Mappern und arbeite sehr gerne mit DataTable und DataSet. Sollten die Daten wirklich persistierte Objekte sein, wäre es dann nicht gleich sinnvoll anstatt einer relationalen Datenbank eine Objektdatenbank wie db4o zu benutzen? Gut, wahrscheinlich hat man als Entwickler selten die freie Wahl...

-yellow

Selbst ein Weg von tausend Meilen beginnt mit einem Schritt (chinesisches Sprichwort).

Mein Blog: Yellow's Blog auf sqlgut.de

F
10.010 Beiträge seit 2004
vor 16 Jahren

Genau, schon mal angeschaut, was eine db4o lizenz im professionellen Umfeld kostet.

Aber leider machen die meisten Entwickler die mit DataSets arbeiten
dann den Fehler die ganze Businesslogik in die UI zu verfrachten.
Validieren in einer WindowsForm ist zwar schnell gemacht, aber dann leider echt ekelig zu warten.

Und gerade wenn man ein Produkt schreibt, das auf verschiedenen Datenbanken
laufen soll, macht sich irgendwann ein ORMapper bezahlt.

Allerdings wenn nur Massendaten zu verarbeiten sind, ist es in der Tat sinnvoller
den Reader zu benutzen, oder DataSets.