Die meisten anderen Firmen hätten hier vermutlich die Flucht nach vorne angetreten und versucht den neuen Fork zu umarmen. Oder wenigstens wichtige Mitarbeiter als Brücke zu behalten, um die Interoperabilität zu gewähren und durch den Ideenaustausch eine gegenseitige Befruchtung zu ermöglichen. Damit hätte Oracle auch gleich verlorenes Vertrauen gut machen machen können. Oracle denkt aber in Konkurrenz bzw. Wettbewerb und vergrault die Community damit noch mehr. Das verstehe ich einfach nicht.

Wer die grundsätzliche Art der Softwareentwicklung in einer Open-Source-Community verstehen will, dem empfehle ich den Klassiker auf dem Gebiet "The Cathedral and the Bazaar". Inzwischen ist man freilich schon wieder etwas weiter, aber die grundsätzlichen Regeln gelten immer noch: die (zeitweilige) Vielfalt der Entwicklungslinien ermöglicht eine breitere Akzeptanz. Die Ideen werden teilweise parallel erprobt, erhalten unmittelbares Feedback durch Beteiligung der "Kunden" während der Entwicklung, aber nicht Linien alle setzen sich durch. Das ist wie bei einem Basar bei dem alles bunt durcheinander zu gehen scheint und viele Dinge gleichzeitig und weitgehend unkoordiniert passieren. Beim Bau einer Kathedrale hingegen gibt es Architekten und genaue Pläne. Deswegen wird eine Kathedralensoftware auch irgendwann mal fertig, während Basar-Software nie fertig ist, sondern in kleineren Schritten immer weiter entwickelt wird.

Mittlerweile bauen aber immer weniger Firmen nach dem Kathedralenmodell Software. Dank agiler Vorgehensmodelle (z.B. Scrum) können einige gute Ansätze aus dem Basarmodell auch von Entwicklern in "proprietären" Softwareschmieden eingesetzt werden. Der damit einhergehende Verständniswandel von Softwareentwicklung und Beteiligten ist aber in den Köpfen der Oracle-Manager offenbar noch nicht angekommen…

Jedenfalls habe ich bei meiner Suche zum Thema "verteilte Transaktionen mit .net" eine kleine Linksammlung angelegt, die ich hiermit der Öffenlichkeit zur Verfügung stelle. Wenn jemand weitere Artikel zu dem Thema kennt, dann bitte ich um einen Link als Kommentar.

Die ".net Enterprise Transaction Services" bieten scheinbar genau das, was man in einer service-orientieren Welt so braucht: offenbar können hier mehrere Services auf unterschiedlichen Computern an der gleichen verteilten Transaktion teilnehmen. Stimmt das? Und wenn ja, wo ist der Haken: Performance?

Den kurzen, übersichtlichen Artikel "Managing Distributed Transactions with ADO.NET 2.0 using TransactionScope" zum Thema TransactionScope fand ich auch hilfreich.

Der Artikel "Distributed Transactions in .NET 2.0" ist zwar auch weiterführend, aber tendenziell etwas mager.

Der etwas älterere Artikel "HOW TO: Perform a Distributed Transaction with a .NET Provider by Using ServicedComponent in Visual C# .NET" von Microsoft hat mir nur bedingt weitergeholfen.

"C# – Die neue Sprache für Microsofts .NET-Plattform" von Eric Gunnerson, bei Galileo-Computing als "Open Book"
Gute Einführung, leider schon etwas ältlich (aus dem Jahre 2000), daher sind die schicken neuen Sachen von .Net 2.0 vermutlich nicht drin…

Das ".Net BlogBook" enthält hingegen jede Menge aktuelle Tipps aus der Praxis.

Ein gutes Vorlesungsskript der FH-Regensburg. Ich wünschte wir hätten so nett zu lesende Skripte bekommen. Ist natürlich etwas theorielastig…

• Man kann Berichte ansehen, die in einem Reporting-Service aufbereitet wurden.
  Diese Nutzung beschreibt Microsoft super ausführlich. Immerhin wird der Reporting-Service inzwischen sogar mit der Express-Edition ausgeliefert.
• Man kann in seinem Projekt einen Bericht erstellen und ihn in seine Anwendung reinkompilieren. Das wird von Microsoft leidlich beschrieben. Man kann damit einen Bericht am erstellen und aufbereiten (mit allen schicken Features der Reporting-Services ohne ihn installieren zu müssen). Leider kann man damit nur genau einen Bericht pro Control ansehen.
• Außerdem kann man den Control dazu nutzen viele verschiedene Berichte anzuzeigen. Im Prinzip kann man sogar beliebige Berichte anzeigen, wenn man bereit ist, den Aufwand zu erbringen. Damit kann man aus den Reporting-Services das schickste nutzen, die Anzeige und das Rendering der Berichte (inkl. Export nach PDF, Excel usw.), ohne eine Server-Anwendung installieren und konfigurieren zu müssen. Warum das von Microsoft nicht an die große Glocke gehangen wird, ist klar, oder? Sie erwähnen zwar mal die Möglichkeit, aber eine Anleitung fand ich nicht…

Zum letzteren fand ich lediglich einen brauchbaren Artikel, der in Visual-Basic kurz skizziert, wie man das anstellen muss: "Take Control of Your Reports with ReportViewer, Part 2". Er ist kostenpfichtig, die Code-Fragmente sind frei zugänglich. Leider wird darin alles in Visual-Basic gemacht. Es hat eine Weile gedauert bis ich das Prinzip verstanden habe. Ich habe folgende Erkenntnisse gewonnen:

Das ReportViewer-Control übernimmt nur die Anzeige des Berichts: also das Rendering und die Aufbereitung der Daten. Alles andere muss die eigene Anwendung erledigen:

• Zusammenstellen des SQL-Statements, mit dem die Daten gelesen werden. Die Query kann man eigentlich auch aus dem Bericht rauslesen, wenn man sich nicht scheut, sie aus dem XML-File zu entnehmen.
• Die Übergabe der im Bericht enthaltenen Parameter. In dem Beispiel wird gezeigt, wie man dem Bericht-Objekt die Parameter entlocken kann.
• Bereitstellen einer Datasource, die dynamisch erstellt werden kann. Nur der Name muss so sein, wie im Bericht angegeben.

Im ersten Schritt kann man so eine Hülle für das ReportViewer-Control schreiben, die dem Entwickler anhand von bestimmten Namens-Konventionen das Leben leicht macht, z.B. DataSource1 oder Param01.
Andererseits ist die Struktur der Berichte (XML-Datei) sehr einsichtig, deswegen kann man sie auch im ersten Schritt auswerten und die Query, deren Parameter und den Namen der Data-Source ermitteln. Im zweiten Schritt muss man das Control lediglich initialisieren und schon hat man ein Universal-ReportViewer-Control.

Es wird einem echt viel Arbeit abgenommen und man muss sich nur um wenige Dinge selber kümmern. Man kann alles Testen, das sich mit SQL ausdrücken lässt: Prozeduren, Funktionen, Views, Trigger, sogar Assemblies.
Ich denke, es eignet sich besonders gut für entwicklungsbegleitendes Testen.

Hier ein paar Schattenseiten, die ich schon fand:

• Für Negativ-Tests muss man gewünschte Fehlermeldungen in einem Catch-Block auffangen und schauen, ob der gewünschte Fehler auftrat. Wenn nicht, muss man einen Fehler werfen. Das geht schon, ist aber unnötig aufwändig: Es wäre schön, wenn man eine Test-Bedingung "Fehler xy tritt auf" angeben könnte.
• Es gibt keine Test-Bedingung, die ein ResultSet mit einer Datei vergleicht. Allerdings war es nur ein geringer Aufwand so eine Erweiterung selber zu schreiben.
• Man kann nicht automatisch die gleichen Tests mit verschiedenen Datenbanken (z.B. mit verschiedenen Datenmengen oder Konstellationen) hintereinander ausführen. Mann muss dazu selber etwas außen rum machen, dass die DBs "austauscht" und die Tests dann neu startet. Dazu hatte ich noch keine Lust, äh Zeit, wird mir aber vermutlich nicht erspart bleiben.

Ich glaube, dass ich langsam aus dem Hype rauskomme und in die Phase "get real" reinrutsche…

Für "meine" etwa 50 Prozeduren habe ich schon etwa 180 Unit-Tests geschrieben. Bei Ausdenken der neuen Tests bzw. Umschreiben der alten (ich testete bislang mit einem eigenen Werkzeug) stoße ich immr wiedre auf kleinere Macken, die nach der Umstellung auf SQL-Server-2005 viel eleganter zu machen sind. Mit den Unit-Tests ist das kein Problem: Vorher Tests laufen lassen, Änderung durchführen und wieder die Tests laufen lassen. Wenn dann kein Fehler kommt, dann kann ich sicher sein, dass die Änderung klar ging.

Mit dem sehr guten Artikel "Database Unit Testing with Team Edition for Database Professionals" fiel mir der Einstieg in die Thematik sehr leicht.

Auf dem Weblog des Autors findet sich übrigens ein Beispiel, wie eigene Testbedingungen anlegen kann. Das klappt ganz gut, nachdem ich aus der Datei "SachTestConditions.extensions.xml" das Attribut "xsi:schemaLocation" vom Element "extensions" entfernt hatte.

Ein Beispiel bei SQL-Server-Central (kostenlose Anmeldung erforderlich), dass jedoch leider einige Patzer enthält, z.B fehlt in der Extension-Xml die Angabe des Attributs xmlns, ist der Artikel "Putting Unit Tests to Work".

Alleine schon wegen dieser tollen Möglichkeit rund um Unit-Tests zu SQL-Server-Datenbankobjekten würde ich jedem Datenbank-Entwickler dazu raten sich diese Edition anzuschaffen. Der Preis ist schon ganz schön hoch, aber der Zugewinn in der QS sollte dem Chef die Ausgabe wert sein…

"Jasper" ist der Codename für "Dynamic ADO.NET 3.0" und bietet angeblich:

• dynamische Klassengenerierung (ohne Konfiguration)
• umfangreiches O/R-Mapping
• automatisches Binding für ASP.NET, WinForms und WPF

Die ersten beiden Punkte lassen aufhorchen und könnten begeistern, immerhin fehlt es hier bisher immer noch ein Stückchen. Der Letzte macht es aber auch ein wenig suspekt, womöglich werden hier die Oberflächen auch wieder so stark an die Datenzugriffsklassen drangeklebt?

Warten wir es ab, interessant wird es auf jeden Fall. Infos aus ersten Hand findet man im Ado-Net-Blog.

Eine ganz hübsche Sammlung zu allen Jasper- Informationen findet man im OakLeaf-Blog: ""Jasper" to Deliver Dynamic ADO.NET 3.0"

Der Download des CTP steht seit zwei Tagen bereit. Als Vorausetzung benötigt man aber das Visual Studio (Codename "Orcas") Beta1…

Auf obiger Seite wird kurz zusammengefasst, was Spec# ist:

Spec# is an experimental language that extends C# with several design-by-contract features. The new features of Spec# include a non-null type system, method pre- and post-conditions, loop invariants, and object invariants. The Spec# Programming System provides design-time checking, run-time checking, and a static verifier. This version of Spec# runs on .NET Framework version 2.

Wer mehr Infos haben will, der wird auf der Homepage von Spec# fündig. Dort ist auch ein Link zum Download für Visual Studio 2003, aber der ist derzeit tot.

Learning by example

Für codeproject.com schrieb Jon Rista eine ganz gute Anleitung, wenn man selber ein AddIn für das Visual-Studio-2005 schreiben will. Es wird anhand eines konkreten Beispiels erklärt: "Line Counter – Writing a Visual Studio 2005 Add-In"

Das ist zwar schon 11 Monate alt, aber sehr gut erklärt und noch aktuell.

Grundlagen in deutsch

Wer es lieber in deutsch mag oder ein Fan von Mirko Matytschak ist, der sollte unbedingt seinen Artikle lesen, der auch in dr MSDN zu finden ist: "Unbegrenzte Möglichkeiten mit Visual Studio Add-ins". Das gesagte bezieht sich aber auf das Visual-Studio-2003 und könnte sich daher im Detail überholt haben.

Details finden sich auch in dem Artikel "New Data Tools Features in Visual Studio Orcas" auf dem VB-Team-Blog. Hier wurde ich überhaupt erst auf das März-CTP aufmerksam.

Glossar:

CTP – Früher nannte man solche Vorabversionen erst Alpha dann Beta, je nach Reifegrad. Zusätzlich dazu verteilt Microsoft jetzt immer wieder auch "Customer Technical Previews" (CTP), um die Kunden während der langen Entwicklungsphasen bei der Stange zu halten.

ORCA – Das ist der Codename für die nächste Version des Visual Studio.

Etliche Tipps gelten auch für das SQL Server Management Studio, wie z.B. "Strg+K, Strg+C" und "Strg+K, Strg+U" zum kommentieren und auskommentieren.