.NET Entwicklung

.NET Entwicklung

Posts 1-10 of 43
  • Christian Hassa
    Christian Hassa    Premium Member   Group moderator
    The company name is only visible to registered members.
    Erfahrungsaustausch mit O/R Mapping und .NET
    Objektrelationales Mapping ist ja keine besonders neue Idee, das Problem existiert ja schon praktisch seit der Einführung der ersten OO Programmiersprachen mit denen auf relationale Datenbanken zugegriffen wurde. Daher gibt es auf vielen Plattformen (z.B. SmallTalk, Java) auch schon relativ lang Erfahrung und ein paar etablierte Produkten, die allgemein bekannt sind.

    In der .NET Welt gab es lange Zeit kaum entsprechende Tools, allen voran hatte Microsoft es unterlassen, ein dementsprechendes Tool für das .NET Framework anzubieten. Das hat eine Reihe von Softwareschmieden dazu veranlasst, ihre eigenen O/R Frameworks zu entwickeln, zuallererst natürlich einmal um in eigenen Projekten die Vorteile einer objektorientierten Entwicklungsplattform im Zusammenspiel mit relationalen Datenbanken nutzen zu können.

    Die zweimalige Ankündigung von ObjectSpaces durch Microsoft (einmal zur PDC 2001, einmal zur PDC 2003) lenkte die Aufmerksamkeit der breiten Masse von .NET Entwicklern auf O/R Mapping. Beiden Ankündigungen von ObjectSpaces folgte *keine* Release, was dazu führte, dass die Nachfrage und das Interesse danach stark gestiegen, jedoch kein übermächtiges (im Sinne von Marketing und Awareness) Produkt vorhanden ist. Das bewegte viele der Softwareschmieden dazu, ihr vordergründig für den eigenen Bedarf entwickeltes Framework als Produkt anzubieten.

    Mittlerweile gibt es eine Reihe von O/R Mapping Tools für die .NET Plattform, von Opensource bis zu kommerziellen Produkten großer Anbieter. Es gibt kaum Tools, die global verbreitet sind und von den (mir) derzeit über 30 bekannten Tools werden wohl nur wenige längerfristig bestehen bleiben.

    Als Hersteller von Genome, einem O/R Mapping Tool für .NET, welches seit Mitte 2001 bei uns intern entwickelt und verwendet wird, und seit Ende 2002 als Produkt erhältlich ist, haben wir dieses Brett ins Leben gerufen, um einen Austausch über die Verwendung von O/R Mapping auf der .NET Plattform zu initiieren.

    Als Anstoß für die weiteren Diskussionen ein paar Themen und Fragen, die wir für relevant halten:

    1) Verwendung und Erfahrung mit O/R Mapping im Allgemeinen:
    wie viele verwenden es bzw. verwenden es bewusst nicht und wie viele haben davon noch gar nicht gehört? Neben den „Unwissenden“, die O/R Mapping noch gar nicht in Betracht gezogen haben, gibt es auch „gebrannte Kinder“, welche O/R Mapping bewusst nicht einsetzen, da sie entweder selbst an der Implementierung eines Frameworks gescheitert sind oder mit Implementierungen in Berührung gekommen sind, die ihren Anforderungen nicht gerecht wurden. Eine Reihe von Mythen und Irrglauben wurde dadurch über O/R Mapping verbreitet. Genügend Themen also, sich auszutauschen.

    2) Diskussion und Vergleich von bestimmten O/R Mapper Implementierungen:
    dieses Thema läuft natürlich Gefahr, sich auf ein allgemeines gegenseitiges „Bashing“ zu reduzieren. Mit ein wenig Disziplin sollte es jedoch möglich sein, objektive Vergleiche zu ziehen um eventuell daraus eine „Benchmark“ für O/R Mapper zu entwickeln. Interessant in diesem Zusammenhang sind auch bereits bekannte Benchmarks wie z.B. „Torpedo“ und Meinungen dazu.

    3) Soziale Aspekte beim Einsatz von O/R Mapping:
    Das Design und Tuning der Datenbank ist oft Domäne eines dedizierten Datenbankadministrators/-designers, der oft mit OO Technologie kaum in Berührung gekommen ist. Durch den Einsatz von O/R Mapping hat sich für uns gezeigt, dass spezielle Aufmerksamkeit der Zusammenarbeit von OO-Spezialisten und DB-Spezialisten zu widmen ist.

    4) Positionierung von O/R Mapping beim Management:
    Unsere Erfahrung ist, dass der Nutzen von O/R Mapping oft von den Entwicklern erkannt wird, jedoch eine Reihe von Hürden beim Management zu überwinden sind, um O/R Mapping auch im eigenen Unternehmen einsetzen zu können. Wie sind die Erfahrungen bei der Entscheidungsfindung für den Einsatz eines O/R Mappers und welche Argumente und Gegenargumente werden dabei verwendet?


    Wir sind gespannt auf interessante Diskussionen zu diesem Thema.

    Weitere Informationen zu Genome findet man unter http://www.genom-e.com
    • 14 Mar 2005, 12:53 pm
  • Post visible to registered members
  • Post visible to registered members
  • René Baron
    René Baron    Premium Member   Group moderator
    The company name is only visible to registered members.
    Re: Erfahrungsaustausch mit O/R Mapping und .NET
    hmm - auf die Gefahr hin dass ich mich hier auf dünnem Eis bewege ...

    Ich sehe natürlich die Vorteile von O/R Mapping ganz klar bei der verkürzten Entwicklungszeite und besseren Wartbarkeit gerade bei komplexen Projekten.

    Andererseits ist für mich, resp. meine Kunden die Datenbank-Performance immer ein absolut kritischer Faktor und ich verwende immer einen grossen Teil meiner Entwicklungszeit mit
    - dem optimalen Design der Datenbank (z.B. De-normalisierung)
    - Desing der richtigen Indizes, Views, Filter und Trigger
    - sorgflältig vorkompilierten Stored Procedures
    - Tools zur ueberwachung und automatischen optimierung der Datenbank

    Inwiefern kommt mir da O/R Mapping entgegen ? - oder müsste ich beim Einsatz von O/R Mapping eventuell bezüglich DB-Performance und Tuningmöglichkeiten Abstriche machen ?
    • 12 Jun 2005, 12:51 pm
  • Post visible to registered members
  • Christian Hassa
    Christian Hassa    Premium Member   Group moderator
    The company name is only visible to registered members.
    Re^2: Erfahrungsaustausch mit O/R Mapping und .NET

    Performance ist eine der häufigsten Einwände (Mythen) gegen O/R Mapping.

    Einige O/R Mapping Tools haben sehr wohl einen gravierenden Nachteil in Bezug auf Performance gegenüber handgeschriebenem SQL. Oft liegt das aber an fehlender Flexibilität in der Abfragesprache, fehlender Beinflussbarkeit der Abfragestrategien und fehlenden Möglichkeiten, das Caching zu optimieren.

    Ein gutes O/R Mapping Tool ist jedoch flexibel genug, entsprechend optimale Abfragen und Ladestrategien zu verwenden und enstprechende Performanceoptimierungen zu unterstützen.

    Der Punkt ist nämlich, dass in einer Applikation 90% der Abfragen keinen Einfluss auf die Performance haben. In diesem Fall zählt viel mehr, dass diese Abfragen wartbar und gekapselt entwickelt werden können. Die restlichen 10% der Abfragen spielen eine mehr oder weniger grosse Rolle in der Performance.

    Bei großen Applikationen ist es nahezu unmöglich *im vorhinein* herauszufinden, welche Abfragen zu jenen 10% gehören, die optimiert werden müssen. Genausowenig sind auch nicht datenbankabfragespezifische Applikationsteile im vorhinein identifizierbar, welche die Hotspots in einer Applikation darstellen werden (abgesehen von konzeptionellen Performance Problemen, die man natürlich schon im Design und auch laufend während der Entwicklung im Auge behalten und vermeiden muß).

    Daher führt man normalerweise nach Fertigstellung der Funktionalität bzw. Iteration Performancetests mit repräsentativen Usecases (entsprechend des erwarteten Anwenderverhaltens) durch, um die tatsächlichen Hotspots zu identifizieren und zu optimieren.

    Bei der Performanceoptimierung wird Code verändert wobei das Ergebnis im Idealfall erhalten bleibt. Meistens werden dabei sogar auch Abstriche in Kauf genommen (Spezialisierung des Codes für einen bestimmten Usecase, Verzicht auf Konsistenz, ...) um den "Hotspot" zu optimieren.

    Im Falle des Datenbankzugriffs kann das zum Beispiel bedeuten, dass Tabellenstrukturen umgebaut werden müssen (denormalisierung, etc.) bzw. Abfragen umformuliert werden.

    Mit einem guten O/R Mapping Tool, sind genau diese Dinge viel leichter möglich, als mit handgeschriebem SQL:

    Stellen Sie sich vor, Sie haben eine Kunden und Personentabelle getrennt dargestellt (Kunde erweitert Person) und wollen diese nach Durchführung ihrer Performancetests in eine Tabelle zusammenführen. Mit einer Vielzahl an manuell kodierten SQL Abfragen ist das nur mit sehr großem Aufwand möglich.

    Mit einem O/R Mapper ist das mit einer kleinen Änderung im Mappingfile erledigt. Gleiches gilt für Abfragestrategien (welche Tabellen werden in das Ergebnis gejoined) und Umformulierung von Abfragelogik: gute O/R Mapper erlauben die nachträgliche Einbringung von Direktiven, um die Anzahl der Abfragen oder den Umfang der abgefragten Daten verändern, ohne dass die bestehende Geschäftslogik (inkl. dem Sinn der Abfragen) davon betroffen wird.

    Auch sind gute O/R Mapper in der Lage *einzelne* Abfrageteile in Stored Functions oder Stored Procedures auszulagern und nahtlos in das Objektmodell einzubinden. Der Punkt ist hier wiederum, nur dann eine SP oder SF zu verwenden, wenn das tatsächlich notwendig ist, da der Preis dafür erhöhter Aufwand in der Wartung und fehlende Kapselung bzw. Flexibilität ist.

    Unsere Erfahrung ist daher, dass mit einem guten O/R Mapper sogar bessere Gesamtergebnisse im Bereich Performance erzielt werden können, vor allem bei grösseren und komplexeren Projekten. "Automatisch" erzeugt ein O/R Mapper nicht den performantesten Code. Jedoch verhindert ein O/RM Tool "pre-mature optimization" und unterstützt bei der auf Tests basierenden Optimierung von Anwendungsperformance. In letzter Konsequenz erlaubt ein O/RM Tool jede Abfrage, die Sie auch manuell schreiben können.


    Rene Baron schrieb am 12.06.2005, 12:51:
    hmm - auf die Gefahr hin dass ich mich hier auf dünnem Eis bewege ...
     
    Ich sehe natürlich die Vorteile von O/R Mapping ganz klar bei der verkürzten Entwicklungszeite und besseren Wartbarkeit gerade bei komplexen Projekten.
     
    Andererseits ist für mich, resp. meine Kunden die Datenbank-Performance immer ein absolut kritischer Faktor und ich verwende immer einen grossen Teil meiner Entwicklungszeit mit - dem optimalen Design der Datenbank (z.B. De-normalisierung)
    - Desing der richtigen Indizes, Views, Filter und Trigger
    - sorgflältig vorkompilierten Stored Procedures
    - Tools zur ueberwachung und automatischen optimierung der Datenbank
     
    Inwiefern kommt mir da O/R Mapping entgegen ? - oder müsste ich beim Einsatz von O/R Mapping eventuell bezüglich DB-Performance und Tuningmöglichkeiten Abstriche machen ?
    • 14 Jun 2005, 4:06 pm
  • Christian Hassa
    Christian Hassa    Premium Member   Group moderator
    The company name is only visible to registered members.
    Re^2: Erfahrungsaustausch mit O/R Mapping und .NET
    Hallo,

    Ich kenne NHibernate und wäre sehr an Ihren Erfahrung damit interessiert.

    Haben Sie damit schon größere/kritsichere Projekte umgesetzt?
    Sind Sie mit der Stabilität und Funktionalität der Betaversion zufrieden (es gibt ja noch keine Release)?


    Ich war letzte Woche auf der Microsoft TechEd in Orlando und habe die BoF Session über NHibernate besucht: bei all dem Hype, der um NHibernate gemacht wird, war ich verweundert dass nur eine handvoll Leute tatsächlich Projekte mit NHibernate umgesetzt haben. Und keines der Projekte war in einer ernstzunehmenden Größenordnung.

    Daher bin ich sehr interessiert, ob NHibernate überhaupt schon von jemanden in größeren Projekten eingesetzt wird - oder ob nur alle darüber reden.

    Von der funktionalen Seite bin ich von NHibernate nicht besonders beindruckt.

    Ein großes Manko sehe ich in den Möglichkeiten der Abfragesprache, und der Tatsache, dass diese die gleichen Limitationen wie SQL hat (fehlende Kapselung, Vermischung von Abfragelogik mit Retrieval Strategie).

    Ein weiteres Problem von NHibernate ist die Art und Weise, wie Updates getracked werden. Das passiert nämlich komperativ, was bei großen Objektgraphen ein Performanceproblem darstellt. Ebenso wird meines Wissens nach jeweils der gesamte Objektstate aktualisiert und nicht nur die spezifischen Änderungen.

    Desweiteren fehlen mir bei NHibernate alternative Transaktionsszenarien.

    In Bezug auf Performance fehlen mir bei NHibernate:
    +) Konfigurierbare Cachingmöglichkeiten
    +) rekursive serverseitige Abfragen
    +) Einbindung von Stored Procedures und RawSQL
    +) Partial Object Population
    +) Formulierung von Batch-Operationen

    Als Plus an NHibernate sehe ich die Nähe zu Hibernate, wodurch existierendes Java KnowHow verwendet werden kann, und eine Vielzahl an existierender Dokumentation (mit Einschränkung) verwendet werden kann. Von den Möglichkeiten, die Hibernate3 bietet, ist NHibernate jedoch weit entfernt.

    mfg
    Christian Hassa


    Andreas Bednarz schrieb am 12.06.2005, 00:18:
    Hallo Herr Hassa,
     
    von meiner Seite kann ich allen wärmstens NHibernate empfählen. Es ist zwar noch nicht so weit wie das J2EE Original, aber die Funktionalität des NET Ports ist komplett ausreichend und sehr "ordentlich". Vor allem bei J2EE/NET Cross Projekten ist es sehr gut anzuwenden und erfordert minimale Einarbeitung.
     
    http://nhibernate.sourceforge.net/
     
    Grüße aus Hannover,
     
    Andreas Bednarz
    printx.org
    • 14 Jun 2005, 4:27 pm
  • Post visible to registered members
  • Volkhard Raetsch
    Volkhard Raetsch    Premium Member
    The company name is only visible to registered members.
    Re^2: Erfahrungsaustausch mit O/R Mapping und .NET
    Dann solltest Du auf IBatis (http://ibatis.apache.org/) setzen. Hier kann man das Datenbankverhalten komplett aussteuern. Es ist sogar die Verwendung von Stored Procedures möglich. Wir setzen das bisher schon mehrfach ein. Hat sich als sehr gut herausgestellt.

    Rene Baron schrieb:
    hmm - auf die Gefahr hin dass ich mich hier auf dünnem Eis bewege ...
     
    Ich sehe natürlich die Vorteile von O/R Mapping ganz klar bei der verkürzten Entwicklungszeite und besseren Wartbarkeit gerade bei komplexen Projekten.
     
    Andererseits ist für mich, resp. meine Kunden die Datenbank-Performance immer ein absolut kritischer Faktor und ich verwende immer einen grossen Teil meiner Entwicklungszeit mit - dem optimalen Design der Datenbank (z.B. De-normalisierung)
    - Desing der richtigen Indizes, Views, Filter und Trigger
    - sorgflältig vorkompilierten Stored Procedures
    - Tools zur ueberwachung und automatischen optimierung der Datenbank
     
    Inwiefern kommt mir da O/R Mapping entgegen ? - oder müsste ich beim Einsatz von O/R Mapping eventuell bezüglich DB-Performance und Tuningmöglichkeiten Abstriche machen ?
    • 20 Oct 2005, 1:59 pm
  • Stefan Papp
    Stefan Papp    Premium Member   Group moderator
    The company name is only visible to registered members.
    Re^3: Erfahrungsaustausch mit O/R Mapping und .NET
    Hallo,


    Wir haben sehr gute Erfahrungen mit Gentle.NET gesammelt. Die Stabilität ist hervorragend und es traten keine Performanceprobleme auf.

    Diejenigen von uns die NHibernate vor ein paar Monaten getestet haben, sind der Meinung, dass noch einige Kinderkrankheiten enthalten wanren. Nichtsdestotrotz werden wir eine neue Version von nHibernate evaluieren, da wir auch Java Projekte haben, woran auch einige .NET Entwickler arbeiten können und ich noch von keiner Version von Gentle für Java gehört habe.

    lg
    Stefan Papp
    • 07 Dec 2005, 3:26 pm