Und ich hatte die "ehrenvolle Aufgabe", den Event mit einer General Session zu eröffnen. Zuerst wollte ich darin typische Vertreter der Persistenztechnologieklassen vorstellen und den Unterschied der Programmiermodelle herausarbeiten. Dann aber... kam mir in der letzten Woche bei der wie immer gerade noch rechtzeitigen ;-) Vorbereitung des Vortrags eine viel bessere Idee: Warum nicht den Teilnehmern sozusagen eine Karte für den Persistenztechnologiedschungel geben? Ist es nicht das, was ein Event wie der p.day leisten soll? Konkrete Guidance und Strukturierungshilfe für ein komplexes Thema? Genau!
Deshalb habe ich - etwas ad hoc, aber immerhin - einen Frage- bzw. Selbsteinschätzungbogen entwickelt und vorgestellt. Der wurde durch die dotnetpro allen Teilnehmern mit ihrer Konferenztasche ausgehändigt. Mit ihm konnten sie angeleitet durch meine Erläuterungen im Vortrag ihren Anforderungen an eine Persistenztechnologie reflektieren und priorisieren - und dann die Aussteller ins Kreuzverhör nehmen. Teilnehmer wie auch Aussteller haben gesagt, das sei eine echte Hilfe gewesen.
"Danke für die vielen Denkanstöße.
Und danke für die Liste. Die ist sehr wertvoll!"
Tibor Odehnal, Teilnehmer am persistence.day
Das freut mich. (Noch besser wäre die Hilfe natürlich gewesen, wenn sie den Ausstellern vorher bekannt gewesen wäre. Dann hätten sie sich dazu schon Gedanken machen können. Naja... nächstes Mal ;-)
Da nun mein Vortrag keinen Code gezeigt hat und recht untechnisch war, biete ich hier einen kleinen Trost: Das Kapitel zum Thema LINQ aus dem Buch ".NET 3.0 kompakt", das ich zusammen mit Christian Weyer geschrieben habe.
Wer also Interesse an LINQ hat oder mal in unserem neuesten Büchlein probelesen will , der klicke hier.
Viel Spaß beim Lesen!
PS: So entspannt und zufrieden sahen übrigens einige Aussteller auf dem p.day aus :
v.l.nr.: Joachim Dürr von iAnywhere, dem Hersteller des Advantage Database Servers, Peter Pohmann von dataweb, dem Hersteller von TurboDb, und Peter Brunner von Vanatec, dem Hersteller des O/R Mappers OpenAccess
2 Kommentare:
Hallo Herr Westphal, ich war auch auf der Konferenz und fand alle Vorträge sehr interessant. Ein bischen schade fand ich, dass die verbreitete OpenSource Alternative NHibernate gar nicht erwähnt wurde.
Ein wenig problematisch sehe ich bei uns in der Firma den Schritt auf ein O/R Mapper Framework zu gehen, sowohl zeitlich als auch finanziell, obwohl ich mal denke, dass sich das zeitlich schnell rentieren würden. Das Problem ist halt, das wir uns für alles inzwischen eigene Lösungen gebaut haben (DbLayer und Db-Surrogate-Klassen) mit allen Vor- und Nachteilen die solche Eigenentwicklungen mit sich bringen. Es wird schwierig, die Geschäftsführung davon zu überzeugen, Geld für etwas auszugeben, was wir eigentlich, wenn auch nicht so gut, schon haben. Ich hoffe aber das ich noch die richtigen Argumente finde, denn ich fand die vorgestellten O/R-Mapper schon sehr sinnvoll.
@Jan: So wie es scheint, ist NHibernate insb. in Deutschland nicht so verbreitet, wie der man meinen könnte. Erwähnt habe ich NHibernate in meinem Vortrag allerdings an einer Stelle. In der Übersicht hatte es aber nichts zu suchen, da es nicht auf dem persistence.day vertreten war. Die NHibernate-Community hat sich nicht berufen gefühlt, Sponsor zu werden oder einen Community Slot zu füllen. Bei Open Source ist halt keiner so recht zuständig.
Ihr habt euch für Build entschieden, wo es jetzt Buy-Optionen gibt. Kann diese Entscheidung rückgängig gemacht werden? Sollte sie das? Das hängt natürlich auch von der Leistung der O/R Mapper gegenüber eurem Framework ab. Ist die Leistung aber vergleichbar oder gar besser, dann solltet ihr wohl umsteigen. Der Grund: Code, den ihr selbst geschrieben habt, müsst ihr auch selbst warten. Das kostet sehr, sehr wahrscheinlich mehr Geld, als einen O/R Mapper einzukaufen.
Natürlich kostet es auch Geld, einen anderen O/R Mapper in euren Code einzubauen. Ob das leicht gelingen kann, hängt vom Grad der Isolation des Persistenzcodes ab. Wenn die schlecht ist... verbietet sich einstweilen womöglich ein Umstieg. Dann solltet ihr aber eine Refaktorisierung anstreben.
-Ralf
Kommentar veröffentlichen
Hinweis: Nur ein Mitglied dieses Blogs kann Kommentare posten.