Jürgen Gutsch

www.asp-net-mvc.com

Jürgen Gutsch — Tue, 03 Nov 2009 23:33:29 PST

Soeben bin ich auf Sean McAlinden's Blog gestoßen und zwar auf eine Beitrag, in dem Sean eine kleine Helferklasse beschreibt, mit der man relativ einfach an eingebettete Ressourcen kommen kann: ASP.Net MVC Embedded Resource Helper Class

Ganz unten unter Beitrag fand ich einen Link auf www.asp-net-mvc.com. Und da ich generell auf alles drauf klicke was irgendwie für ich interessant sein könnte. Fand ich eine Seite vor die sowohl von Sean McAlinden als auch von Paul Thorrington. Was zuerst aussieht wie eine kommerzielle Website entpuppte sich als Präsentation kleiner und feiner ASP.NET MVC Helfer. Insgesamt gibt es sieben kleine Helfer zum anschauen, herunterladen und nutzen.

http://www.asp-net-mvc.com/MvcHelpers

Stirnrunzeln über “Wie viel Sinn machen Unittests?”

Jürgen Gutsch — Mon, 02 Nov 2009 00:44:12 PST

Seit Oktober 2009 verfolge ich mit Begeisterung das Streitgespräch zwischen Golo Roden und Peter Bucher. Beide Autoren stellen sich jeden Monat von neuem diversen Fragen und Problemen aus dem Bereich der Softwareentwicklung.

Auch dieses mal kann man wieder über ein Spannendes Thema lesen: Wie viel Sinn machen Unittests?

Diesmal allerdings fühle ich mich gezwungen selber ein Kommentar über den neuesten Beitrag zu schreiben. Denn das erste mal seit dieser Serie bin ich sehr erstaunt, bzw. sogar leicht erschreckt, über Golos Beitrag.

So schreibt Golo, dass Unit Tests zwar wünschenswert sind und und durchaus Sinn machen, allerdings nur an explizit ausgewällten Stellen:

Golo schrieb:
Wie viel Sinn machen Unittests also nun? Zusammengefasst kann man sagen, dass Unittests – an der richtigen Stelle eingesetzt – durchaus Sinn ergeben, dass diese Stellen aber explizit ausgewählt werden sollten.

Des weiteren schreibt er, dass eine 100%ige Testabdeckung zwar wünschenswert ist, aber in der Praxis kaum möglich ist und sogar auf kosten der OOP geht.

Als Begründung nennt er drei Aspekte, auf die ich hier etwas eingehen möchte:

Golo schrieb:
Der bestehende objektorientierte Aufbau ist unter OOP- und stilistischen Aspekten sauber umgesetzt, läuft einer guten Testbarkeit allerdings zuwider.

Diesen ersten Aspekt kann ich leider nicht nachvollziehen, bzw. halte ihn aus meiner Erfahrung heraus sogar für paradox. Im Gegenteil bin ich der Meinung, dass eine saubere, allen Regeln des OOP entsprechende Architektur testbarer ist. Ich gehe sogar noch weiter und behaupte, dass eine mir TDD umgesetzte Anwendung OOP besser umsetzen kann als eine, nicht mit Unit Tests abgedeckte Anwendung.

Denkt man darüber nach was Unit Tests eigentlich sind, nämlich Tests der kleinsten vorhandenen Units, beeinträchtig das keineswegs negativ den aufbau der Anwendung nach allen regeln der OOP. Ein Unit Test testet die kleineste ansprechbare Einheit einer Klasse, das ist eine Methode oder eine Eigenschaft, aber weder deren Abhängigkeiten, noch komplexe Routinen und Szenarien.

Unit Tests unterbinden Abhängigkeiten:

Golo schrieb:
Es bestehen zahlreiche Abhängigkeiten zu externen Komponenten, die sich nicht oder nur mit sehr viel Aufwand simulieren lassen.

Eine saubere Architektur besteht ohne Abhängigkeiten. Mit Hilfe von IoC Containern und Dependency Injection werden Abhängigkeiten gelöst. Dadurch lassen sich die einzelnen Units noch einfacher Testen. Dadurch lassen sich z. B. ohne Aufwand andere spezielle für diese Tests benötigte Bibliotheken laden. Das wiederspricht also schon dem zweiten Aspekt. Beispielswiese lässt sich für den Unit Test eine Library laden, die den Zugriff auf eine Im-Memory-Datenbank ermöglicht, statt auf einen SQL Server Datenbank.

Eine weitere Möglichkeit sich in in Unit Tests von Abhängigkeiten zu lösen sind Mocking Frameworks wie z. B: RhinoMocks:

Golo schrieb:
Es bestehen Abhängigkeiten zur konkreten Laufzeitumgebung, die sich nicht oder nur mit sehr viel Aufwand nachbilden lassen.

Mocking Frameworks werden genutzt um z. B. abhängige Klassen zu simulieren. Anhand eines Interfaces werden “gefälschte” Objekte erzeigt, die lediglich die benötigten Funktionen bereitstellen und die gewünschten werte liefern.

Datenzugriffsklassen, Dateienzugriffsklassen, eigentlich alle Abhängigkeiten lassen sich in einer sauberen Umgebung simulieren und der Unit Test konzentriert sich einzig und allein auf das Unit, statt Abhängigkeiten berücksichtigen zu müssen.

Golo schrieb:
Um Webbrowser-spezifisches Verhalten zu simulieren, müssten die Eigenheiten des jeweiligen Webbrowsers im Unittest nachgebildet werden. Alternativ könnten der entsprechenden gewünschte Webbrowser automatisiert werden – was seinerseits allerdings einen ziemlichen Aufwand nach sich zieht.

Das ist meiner Meinung nach die Aufgabe eines integrationstests, nicht die eines Unit Tests. Da hier ein komplettverhalten getestet wird und nicht das Verhalten einer einzelnen Unit. Um diese Unit zu testen muss der HttpRequest der von der Unit benötigt wird, simuliert werden.

Golo schrieb:
Ebenfalls problematisch ist multithreaded Code, sofern bestimmte Konstellationen in den einzelnen Threads getestet werden sollen – da das Umschalten zwischen den Threads vom aktuellen Kontext des Prozessors beziehungsweise des Betriebssystems abhängt, kann sich das Verhalten von Ausführung zu Ausführung unterscheiden.

Auch hier sollte der Unit Test nicht den Thread testen , sondern die Units die innerhalb der Threads arbeiten, alles andere wäre kein Unit Test.

Mein Fazit:

Die Benutzung von Unit Tests von möglichen Abhängigkeiten “abhängig zu machen” ist in Zeiten mit IOC Containern und Mocking Frameworks nicht mehr haltbar. Mit Hilfe von diesen Hilfsmitteln ist garantiert eine Testabdeckung von annähernd 100% machbar.

Update:

Hier noch ein Statement zum Thema von Thomas Bandt.

Lesenswert sind auch die Kommentare zu Golos Beitrag unter anderem auch von Ralf Westphal.

Mein Fazit (das zweite):

Wie Thomas kann ich bestätigen dass TDD am Anfang sehr, sehr schwierig ist. Wenn man Jahrelang einfach drauf los entwickelt hat, ist es ein wahrer Kraftakt und es erfordert eine menge Konzentration uns Selbstdisziplin Testgetrieben zu entwickeln.

Zweiter Start mit NHibernate

Jürgen Gutsch — Mon, 28 Sep 2009 13:05:00 PDT

Es ist eine ganze Weile her seit ich mir das letzte Mal NHibernate angeschaut habe. Damals hielt ich NHibernate für zu unflexibel und zu kompliziert, bzw. aufwändig in der Konfiguration. Zumindest damals musste das Mapping der Datenbank auf die einzelnen Objekte in XML-Dateien geschrieben werden. Anschließend wurde per externes Programm, aus den Mapping Klassen generiert, die dann für den Zugriff auf die Datenbank genutzt werden konnten. Gerade die Nutzung eines externen Tools zur Generierung der nötigen Klassen erschien mir sehr umständlich.

Vor ein paar Wochen war es wieder so weit, dass ich mir NHibernate angeschaut habe.

Der Grund waren ein paar positive Äußerungen in der .NET Community. Dort war immer wieder zu lesen, wie gut NHibernate im Zusammenhang mit Fluent NHibernate und LINQ to NHibernate sei. Alleine schon die Aussicht auf LINQ und de Konfiguration über Fluent Interfaces machten mich wieder neugierig auf den am häufigsten erwähnten OR-Mapper.

Enttäuscht wurde ich nicht, ganz im Gegenteil. Mit dem Fluent NHibernate und LINQ to NHibernate ist es eine Freude mit NHibernate zu arbeiten. Nicht nur dass man ganz ohne XML-Konfigurationen auskommt, mit Hilfe des Fluent NHibernate lässt sich das Mapping und die Konfiguration per .NET Code schreiben. Also ob das nicht genug wäre, lässt sich mit Fluent NHibernate sogar die Datenbank dann aus dem erstellten Mapping und der Konfiguration generieren.

Hier mal das Ergebnis meiner ersten Spielerei.

Benötigt werden Fluent NHibernate (welches unter folgender URL heruntergeladen werden kann: http://fluentnhibernate.org/, die NHibernate.dll ist dort bereits enthalten) und LINQ to NHibernate (http://sourceforge.net/projects/nhibernate/files/

Vorbereitung

Angefangen hab ich mit der Erstellung meiner Daten-Objekte

Person.cs

public class Person: Entity<Person> { protected override void Initialize() { Projects = new List<Project>(); Tasks = new List<Task>(); } public virtual List<Project> Projects { get; set; } public virtual List<Task> Tasks { get; set; } public virtual string FirstName { get; set; } public virtual string LastName { get; set; } public virtual string Email { get; set; } public virtual string Telefone { get; set; } }

Projekt.cs

public class Project: Entity<Project> { protected override void Initialize() { Persons = new List<Person>(); Tasks = new List<Task>(); } public virtual List<Person> Persons { get; set; } public virtual List<Task> Tasks { get; set; } public virtual string Name { get; set; } public virtual string Description { get; set; } public virtual DateTime StartDate { get; set; } public virtual DateTime EndDate { get; set; } }

Task.cs

public class Task: Entity<Task> { public virtual Person Person { get; set; } public virtual Project Project { get; set; } public virtual string Name { get; set; } public virtual string Description { get; set; } public virtual DateTime StartDate { get; set; } public virtual DateTime EndDate { get; set; } }

Wie man jetzt evtl. erkennen kann ist eine kleine, einfache Aufgabenverwaltung geplant. Alle drei Objekte erben von einer generischen Basisklasse die weitere Funktionen und die Eigenschaft Id, vom Typ Guid – die in jeder Klasse enthalten ist – bereitstellt.

Mapping

Jetzt wird es dann eigentlich erst interessant: per Fluent NHibernate müssen die Mappings erzeugt werden. Als erste für die Person-Klasse:

public class PersonClassMap: ClassMap<Person> { public PersonClassMap() { Table("Persons"); Id(d => d.Id).GeneratedBy.Guid(); Map(d => d.FirstName).Not.Nullable().Length(50); Map(d => d.LastName).Not.Nullable().Length(50); Map(d => d.Email).Not.Nullable().Length(50); Map(d => d.Telefone).Not.Nullable().Length(50); HasMany(d => d.Tasks) .Cascade.All() .KeyColumn("PersonId") .Inverse(); HasManyToMany(d => d.Projects) .Cascade.All() .Table("Person2Project") .ParentKeyColumn("PersonId") .ChildKeyColumn("ProjectId"); } }

Als erste wird hier der Name der Datenbank-Tabelle definiert. Anschließend mit der Methode Id() der Primärschlüssel. GeneratedBy.Guid() gibt an dass es sich um einen Autogenerierten Guid-Wert handeln soll.

Die Methode Map ist die einfachste, sie mappt lediglich die Eigenschaften auf die Felder in der Datenbank. Not.Nullable()und Length(50) sind sprechend.

Interessant wird es mit HasMany(), hier wird definiert, dass einer Person mehrere Aufgaben zugewiesen sein können. KeyColumn("PersonId") zeigt auf den Fremdschlüssel in der Tabelle „Tasks“. Inverse zeig an dass es das Gegenstück zur Referenzierung in der Klasse Task ist. Dort sieht die Referenz wie folgt aus:

References(r => r.Person, "PersonId");

Die Angabe des Spaltennamens (2. Parameter) ist notwendig wenn man diesen nicht autogeneriert haben möchte, einem bestimmten Namensschema in der Datenbank folgen möchte oder bereits einen Namen in der Datenbank vergeben hat Kniffliger als HasMany() ist HasManyToMany() hier wird eine n:m Beziehung dargestellt und definiert, dass mehrere Personen mehreren Projekten zugeordnet werden können. Wenn der Tabellenname nicht autogeneriert werden soll muss dieser angegeben werden, genauso wie die Spalten. Erscheint zunächst einfach, allerdings muss man beachten, dass das Gegenstück (im Mapping für die Projekte) rückwärts verweist:

HasManyToMany(d => d.Persons) .Cascade.All() .Table("Person2Project") .ParentKeyColumn("ProjectId") .ChildKeyColumn("PersonId") .Inverse();

Man sieht, die Spaltennamen für ParentKeyColumn sind vertauscht und es muss wieder ein Inverse() angehängt sein.

Die anderen beiden Mappings sehen wie folgt aus:

public class ProjectClassMap: ClassMap<Project> { public ProjectClassMap() { Table("Projects"); Id(d => d.Id).GeneratedBy.Guid(); Map(d => d.Name).Not.Nullable().Length(50); Map(d => d.Description).Not.Nullable().Length(4000); Map(d => d.EndDate).Not.Nullable(); Map(d => d.StartDate).Not.Nullable(); HasManyToMany(d => d.Persons) .Cascade.All() .Table("Person2Project") .ParentKeyColumn("ProjectId") .ChildKeyColumn("PersonId") .Inverse(); HasMany(d => d.Tasks).Cascade.All().KeyColumn("ProjectId").Inverse(); } } public class TaskClassMap: ClassMap<Task> { public TaskClassMap() { Table("Tasks"); Id(d => d.Id).GeneratedBy.Guid(); Map(d => d.Name).Not.Nullable().Length(50); Map(d => d.Description).Not.Nullable().Length(4000); Map(d => d.EndDate).Not.Nullable(); Map(d => d.StartDate).Not.Nullable(); References(r => r.Project, "ProjectId"); References(r => r.Person, "PersonId"); } }

Konfiguration

Im nächsten Schritt muss die Verbindung zur Datenbank konfiguriert werden und bei Bedarf eine SessionFactory erzeugt werden. Dazu habe ich mit eine statische Klasse angelegt die wiederum zwei Methode enthält: Die erste Methode erstellt die Konfiguration und die Zweite Methode erstellt die SessionFactory anhand dieser Konfiguration.

public static FluentConfiguration CreateConfiguration() { return Fluently.Configure() .Database(MsSqlConfiguration.MsSql2005 .ConnectionString(c => c.FromAppSetting("DbConnection")) .ShowSql()) .Mappings(m => m.FluentMappings .AddFromAssemblyOf<IEntity>()); }

Im ersten Teil der Fluently Configuration wird die Verbindung zur Datenbank definiert. Hierfür gibt es verschiedenste Möglichkeiten. (Mehr Möglichkeiten lassen sich aus der Dokumentation entnehmen: http://wiki.fluentnhibernate.org/Main_Page) Ich habe MS SQL 2005 als Datenbankserver gewählt und lese den ConnectionString aus den App.Settings, bzw. der Web.Config aus. Außerdem möchte ich bei Fehlern den SQL-String sehen: ShowSql()

Anschließend wird das Mapping zugewiesen. Das geschieht ganz einfach indem man dem Fluent NHibernate sagt, wo die Assembly mit den Mappings liegen. Es werden automatisch alle Klassen als Mapping erkannt die von ClassMap<T> erben.

public static ISessionFactory CreateSessionFactory() { return CreateConfiguration().BuildSessionFactory(); }

Die zweite Methode ruft die erste auf und erstellt eine neue SessionFactory. Ich habe die Configuration von der Erstellung der Session getrennt um für die Generierung der Datenbank einen Konfigurationspunkt – für die Generierung der Datenbank – dazwischen zuhängen, die ich für die einfache Erzeugung der SessionFactory nicht benötige.

public void SetupDatabase() { FluentConfiguration conf = NHConfiguration.CreateConfiguration(); conf.ExposeConfiguration(BuildSchema).BuildSessionFactory(); } private static void BuildSchema(Configuration conf) { new SchemaExport(conf).Drop(false, true); new SchemaExport(conf).Create(false, true); }

Mit der Methode ExposeConfiguration() werden Anweisungen zum Exportieren des Datenbankschemas eingebunden. Das Schema wird in dem Fall in die Datenbank selber exportiert. Es wird also die Datenbank erstellt.

Es empfiehlt sich die SessionFactory global, anwendungsweit bereit zu halten, da die Erzeugung der Factory sonst recht unperformant ist. Schließlich muss das Schema erst anhand des erstellten Mappings generiert werden

private static ISessionFactory sessionFactory; public static ISessionFactory SessionFactory { get { if (sessionFactory == null) sessionFactory = NHConfiguration.CreateSessionFactory(); return sessionFactory; } }

LINQ to NHibernate

Eine Session kann dann innerhalb eines Using-Blocks geöffnet werden:

using(var session = sessionFactory.OpenSession()) { }

Innerhalb des Blocks kann dann endlich auch LINQ to NHibernate zum Einsatz kommen:

var q = from a in session.Linq<Person>() where a.FirstName != "" select a;

Die generische Methode Linq<T>() liefert ein Ergebnis vom Typ INHibernateQueryable<T> das wiederum von IQueryable<T> und IEnumerable<T> und somit wiederum bequem per LINQ abgefragt werden kann.

Fazit

NHibernate ist dadurch natürlich recht schnell einsetzbar, bequemer und auch etwas flexibler, denn das Mapping und auch die Konfiguration lassen sich theoretisch so natürlich auch dynamisch erzeugen. Die Benutzung von LINQ erleichtert die Abfragen ungemein. Fluent NHibernate macht die Konfiguration und das Mapping lesbarer.

Ich denke mit den beiden oben vorgestellten Erweiterungen ist NHibernate wirklich eines der genialsten OR-Mapper.

Update:
Das Beispielprojekt gibt es hier zum herunterladen: NHibernateTestApplication.zip (2.4MB)

jQuery Visual Cheat Sheet

Jürgen Gutsch — Thu, 24 Sep 2009 23:33:31 PDT

Von Antonio Lupetti gibt es ein recht ausführliches jQuery Cheat Sheet zum kostenlosen Download. Das Cheaat Sheet enthält eine Übersicht über die wichtigsten jQuery Funktionen, sowie jQuery Selektoren und einige Beispiele zur Anwendung der Funktionen:

http://woork.blogspot.com/2009/09/jquery-visual-cheat-sheet.html

VSTS beim .NET-Stammtisch Konstanz-Kreuzlingen

Jürgen Gutsch — Wed, 26 Aug 2009 00:55:57 PDT

Etwas verspätet liefere ich hier noch einen kurzer Rückblick auf das sechste Treffen des .NET-Stammtisch Konstanz-Kreuzlingen.

Wie immer bin ich um 18:30Uhr im Raum F023 in der FH-Konstanz angekommen um die Session vorzubereiten. Strom und Beamer zu prüfen und die Videokamera aufzustellen. Diesmal war ich nicht der erste, denn Thomas stand schon drin und richtete den Laptop für seine Präsentation.

Thomas zeigte viele Neuerungen in den VSTS 2010 auch anhand einiger live Demos.

Als beeindrucktesten Neuerungen empfand ich die hierarchischen Workitems, sowie die viel Bessere Unterstützung der Tester unter anderem auch mit dem neuen Workitem-Typ “Testcase”, den Testaufzeichnungen und dem Videomitschnitt während des Testens. Der Entwickler kann so fehlgeschlagenen Tests nachvollziehen und muss unter Umständen nicht lange nach dem Fehler suchen. Auch für die Architekten wurden einige Neuerungen hinzugefügt.

Insgesamt werde ich wohl jedem empfehlen VSTS 2010 einzusetzen, bzw. auf die neue Version updaten, sobald sie Verfügbar ist.

Das Video und die Bilder zum Vortrag werde ich in den nächsten Wochen auf der Website des .NET-Stammtisch veröffentlichen.

Anschließend gingen wir alle in das Brauhaus wo wir in gemütlicher Atmosphäre, bei Frischgebrautem, weiter zum Thema Diskutieren konnten.

Danke nochmal an Thomas, dass er extra wegen uns aus Erlangen, zu uns nach Konstanz runter geheizt ist. :-)

Grenzfälle – Wann ist Code Clean?

Jürgen Gutsch — Thu, 20 Aug 2009 02:20:00 PDT

Aus meinem letzten Blogpost entwickelte sich eine interessante Diskussion zum Thema Clean Code.

Im Grunde ging es in dem Blogpost darum, dass ich mich beschwerte, dass es in LINQ to XML keine “saubere” Möglichkeit gibt XElements mit Namespaces abzufragen. Außer mit einer vom Peter zur Verfügung gestellten Extension Method.

René wies mich per Kommentar darauf hin, dass man auch die statische Methode XName.Get() verwenden könne um Namen für XElemente mit Namespaces zu generieren.

Ich übernahm Renés Idee wie folgt:
XDocument xdoc = XDocument.Load(xmlResponseReader); XName xname = XName.Get("multistatus", "DAV:"); XElement xelement = xdoc.Element(xname);

Damit ging die ganze Diskussion los :-)

René war nun der Ansicht, dass diese drei Zeilen nicht Clean Code seien, da die Erzeugung einer separaten Variablen, die den Wert aus der statischen Methode zugewiesen bekommt, unnötig sei.

René schrieb:
In Bezug auf statische Methode bleibe ich aber bei der Aussage, dass wenn ich den Wert nur 1 mal benötige, dann rufe ich die Methode direkt auf, andernfalls nutze ich einen zusätzlichen Parameter.

René hat absolut recht, was die gezeigten Codes angeht. Die sind klein genug :-)

René und ich haben allerdings nun die unterschiedlichen Anforderungen nicht Berücksichtigt. Der im Blogpost dargestellte Code war natürlich vereinfacht, um das Prinzip zu veranschaulichen. In Wirklichkeit habe ich ein relativ großes XML mit verschiedensten Elementen deren Werte ich abfragen möchte.

Um jetzt mehrere XElemente abzufragen, sähe der Code nach Renés variante so aus:
string nsDAV = “DAV:”; Folder inboxFolder = new Folder(); inboxFolder.HRef = xfolder.Element(XName.Get(“href”, nsDAV)).Value; inboxFolder.DisplayName= xfolder.Element(XName.Get(“displayname”, nsDAV)).Value; inboxFolder.FolderSize= xfolder.Element(XName.Get(“foldersize”, nsDAV)).Value; inboxFolder.HasChildren= xfolder.Element(XName.Get(“haschildren”, nsDAV)).Value; inboxFolder.HasSubs= xfolder.Element(XName.Get(“hassubs”, nsDAV)).Value; // …

Eine Variable vom Typ XName zu erstellen macht hier natürlich keinen Sinn

Aus meiner Sicht bläht diese statische Methode den Code allerdings mehr auf, als die gezeigten Extension Methods:
XNamespace nsDAV = "DAV:"; Folder inboxFolder = new Folder(); inboxFolder.HRef = xfolder.Element(nsDAV, “href”).Value; inboxFolder.DisplayName= xfolder.Element(nsDAV, “displayname”).Value; inboxFolder.FolderSize= xfolder.Element(nsDAV, “foldersize”).Value; inboxFolder.HasChildren= xfolder.Element(nsDAV, “haschildren”).Value; inboxFolder.HasSubs= xfolder.Element(nsDAV, “hassubs”).Value; // …

Zurück zum Clean Code: René war der Meinung das es kein Clean Code sei, wenn ich eine separate Variablenzuweisung schreibe. Ich dagegen bin der Meinung, dass man lieber zwei Zeilen schreiben sollte, als zu viele Anweisungen in eine Zeile zu setzen. Ich bin der Meinung das Der Code für jeden vor allem einfach lesbar sein sollte. Je mehr Anweisungen in einer Zeile zu finden sind, desto länger verharrt der “Leser” in der Zeile und desto schwieriger ist es die Zeile schnell zu verstehen. (Und mir ist es dabei egal, ob der Leser ein Einsteiger oder ein erfahrener Entwickler ist)

Natürlich kann es auch hier Ausnahmen geben. In dem letzten Code (oben) habe ich die Ermittlung des XElements und das Auslesen dessen Wertes in eine Zeile gesetzt. Hier wird allerdings auch der Lesefluss nicht beeinträchtigt:
XElement ermitteln => seinen Wert auslesen

An der Stelle habe ich natürlich die extremen Ansicht von Robert C. Martin übernommen, der in seinem Buch Clean Code schreibt, man solle den Code wie einen Zeitungsartikel lesen können. Das setzt nicht nur Lesbarkeit voraus, sondern auch die Einhaltung eines Lesefluss.

Nebenbei: ReSharper beeinflusst: Habe gerade versucht im Live Writer einen Schreibfehler mit [Alt][Enter] zu korrigieren *fg*

René schrieb:
Mein Verständnis von "Clean Code" fängt da an, wo der Code optimiert ist, funktionell korrekt und verständlich. Wenn ich nur den Schwerpunkt auf Verständlichkeit lege, dann hat das wenig mit "Clean Code" im eigentlichen Sinne zu tun.

Clean Code entsteht nur aus einem längeren Prozess heraus und kann nicht einfach so erzeugt, bzw. geschrieben werden. Clean Code entsteht unter anderem durch die Einhaltung der Prinzipien und Regeln des CCD. Clean Code entsteht dabei vor allem aus Wiederholungen von Reviews und Refactoring. Natürlich muss die Funktionalität des Codes immer im Vordergrund stehen, aber beim nachträglichen Bearbeiten seines Codes sollte nach und nach auch an der Lesbarkeit des Codes gearbeitet werden.

Pfadfinderregel:
Verlasse einen Ort sauberer, als du ihn vorgefunden hast.

Zu Ralfs Uommentar:

Jetzt ich gehe mal schnell auf den Kommentar von Ralf Westphal ein:

Ralf schrieb:
Ob
XDocument xdoc = XDocument.Load(xmlResponseReader); XElement xelement = xdoc.Element("{DAV:}multistatus");

wirklich viel umständlicher ist
XDocument xdoc = XDocument.Load(xmlResponseReader); XNamespace ns = "DAV:"; XElement xelement = xdoc.Element(ns, "multistatus");

wage ich eigentlich nicht zu beurteilen.

Stichwort: Redundanzen ;-)
Der Namespace “DAV:” kann öfter vorkommen. Ihn jedes Mal angeben zu müssen ist mühsam. Zudem lenkt der Namespace vom eigentlichen Elementnamen ab. Zumindest ist das die Erfahrung beim schreiben des Codes. Wenn man allerdings nur diese kleinen Codesnippets für sich betrachtet ist es wirklich egal.

Ralf schrieb:
Mir schiene jedoch eine Ext Meth, der ich keinen Namespace übergeben muss, noch geeigneter:
XDocument xdoc = XDocument.Load(xmlResponseReader); XElement xelement = xdoc.Element("DAV:", "multistatus");

Bei so einer Extension Methode sehe ich keine Probleme. Allerdings arbeite ich in der Regel ungerne mit Strings, wenn es sich vermeiden lässt. Wenn es ein Objekt gibt versuche ich dieses zu nutzen.

Ralf schrieb:
An CCD wurde die Frage gestellt, ob 1 Statement pro Zeile angezeigt sei.

Meine Meinung dazu: da ist unter dem Radar von CCD

Logisch, das ist ja auch nicht Aufgabe des CCD das zu definieren. Wie oben bereits geschrieben gibt an dieser Stelle Robert C. Martin eine Empfehlung wie der Code seiner Ansicht nach am besten auszusehen hat. CCD verweist ja lediglich auf sein Buch.

Ralf schrieb:
Was der eine oder andere für lesbar hält, fällt in die Nähe eines Geschmacksurteils…

Im Detail, ja.

Ralf schrieb:
Das Gesamtbild muss stimmen. Und das kann im Detail dann auch mal unterschiedlich aussehen

Logisch.

Ralf schrieb:
Ich wäre zwar nicht allzu traurig, wenn C# nicht mehr als eine Anweisung pro Zeile zuließe, doch ich nehme gern auch die Möglichkeit mit, dass es mehrere sein dürfen.

Dem kann ich nur zustimmen…

Ralf schrieb:
Noch ein Wort zu statischen Methoden, die in der Diskussion auftauchten. Wenn die im API drinstecken, dann kann man nix machen. Sollten wir selbst aber statische Methoden schreiben? Eher nicht. (Auch wenn R# immer mal wieder vorschlägt, eine Methode statisch zu machen.) Der Grund: static methods don´t compose.

Da statische Methoden keine Interfacemethoden implementieren können, kann man ihre Funktionalität nicht gut injizieren. (Von Funktionszeigern darauf sehe ich mal ab.)

Dito…

Zeilenlänte und Schachtelungstiefe

Und damit damit folgende Aussage – die nicht ganz zum Ursprünglichen Thema passt - nicht in den Untiefen der Kommentarfunktion verloren geht, nehme ich sie ebenfalls hier mit rein.

Ralf schrieb:
Wichtiger finde ich zwei andere Dimensionen:

-Zeilenlänge

-Schachtelungstiefe

Eine Zeile mit wievielen Anweisungen auch immer sollte nicht über eine normale Editorfensterbreite hinausgehen. Wenn man scrollen muss, dann sinkt die Verständlichkeit bzw. die Aufnahmegeschwindigkeit rapide.

Und ich finde Schachtelungen beobachtenswert. Es ist ein Unterschied, ob ich

A(B(C()));

oder

var c=C();

var b=B(c);

A(b);

schreibe. Letzteres macht mehr Aufwand, ist aber flüssiger zu lesen, weil man von oben nach unten lesen kann.

Bei der Schachtelung kehrt sich die Leserichtung quasi um: man muss von innen nach außen, d.h. eher von rechts nach links lesen. Das hakt schnell mal. Da hilft auch eine andere Schreibweise nicht viel wie

A(

B(

C()

)

);

Deshalb bin ich ja ein Freund von Flow-APIs oder allgm Fluent Interfaces. Die machen nicht nur bei async Verarbeitung das Verständnis und die Notation einfacher.

Wer die Variablen b und c scheut, der könnte doch vielleicht so lesbarer schreiben:

C | B | A

Das ist in C# natürlich nicht so recht möglich. Wie wäre es jedoch mit:

Flow

.From(C)

.To(B)

.To(A)

.Execute();

Sieht für so ein kleines Beispiel etwas überkandidelt aus. Aber wenn die Szenarien größer werden, halte ich das für ein unterschätztes Programmiermodell.

Ich bedanke mich bei allen beteiligten für die anregende Diskussion. Ich finde es immer wieder schön, wenn ein einfacher Blogpsot so eine Diskussion losreißen kann.

LINQ to XML: Queries auf XML mit Namespaces

Jürgen Gutsch — Thu, 13 Aug 2009 02:30:00 PDT

Beim Zugriff auf XML mit bestimmten XML-Namespaces kommt es beim herkömmlichen Queries zu einem Fehler. Wie auch beim XMLDoxument muss beim den Abfragen auf bestimmte Knoten ein Namespace angegeben werden.

Ausgangspunkt bei mir ist eine Abfrage per WebDAV auf einen Exchange Server, bei der ich ungefähr folgende Antwort erhalte:
<?xml version="1.0" ?> <a:multistatus xmlns:b="urn:uuid:c2f41010-65b3-11d1-a29f-00aa00c14882/" xmlns:d="urn:schemas:httpmail:" xmlns:c="xml:" xmlns:a="DAV:"> <a:response> <a:href>http://mdomain/exchange/Account/</a:href> <a:propstat> <a:status>HTTP/1.1 200 OK</a:status> <a:prop> </a:prop> </a:propstat> </a:response> </a:multistatus>

Folgende Abfrage liefert einen Fehler:
XDocument xdoc = XDocument.Load(xmlResponseReader); XElement xelement = xdoc.Element("a:multistatus");

XmlException: The ':' character, hexadecimal value 0x3A, cannot be included in a name.

Um das Element nun fehlerfrei zu erhalten muss es wie folgt abgefragt werden:
XDocument xdoc = XDocument.Load(xmlResponseReader); XElement xelement = xdoc.Element("{DAV:}multistatus");

Damit haben wir den – aus meiner Sicht - ersten und einzigen, aber recht großen Nachteil von LINQ to XML gefunden: Die Namespaces müssen direkt in den Namen des Elements eingegeben werden.

Die Lösung die in der MSDN angeboten wird, ist auch nicht besser:
XDocument xdoc = XDocument.Load(xmlResponseReader); XNamespace a = "DAV:"; XElement xelement = xdoc.Element(a + "multistatus");

Mir stellt sich hier die Frage: Wieso erstelle ich ein XNamespace-Object wenn ich es dann doch per String-Gebastel in den Elementnamen einbauen muss. Der Kommentator in der MSDN Dokumentation ist ganz offensichtlich der selben Meinung.

Peter hat für dieses Problem eine kleine elegante Lösung, indem er für die Methoden Element und Elements jeweils eine Extension Methode geschrieben hat:
public static IEnumerable<XElement> Elements( this XContainer source, XNamespace ns, string name) { return source.Elements(ns + name); } public static XElement Element( this XContainer source, XNamespace ns, string name) { return source.Element(ns + name); }

So kann ich wenigstens außerhalb der Extension Methoden ohne String-Gebastel auskommen:
XDocument xdoc = XDocument.Load(xmlResponseReader); XNamespace a = "DAV:"; XElement xelement = xdoc.Element(a, "multistatus");

René hat mich per Kommentar darauf hingewiesen, dass man die Elemente natürlich auch per XName abfragen kann. Das ganze sieht dann so aus:
XDocument xdoc = XDocument.Load(xmlResponseReader); XName xname = XName.Get("multistatus", "DAV:"); XElement xelement = xdoc.Element(xname);

Sechstes Treffen des .NET-Stammtisch Konstanz-Kreuzlingen

Jürgen Gutsch — Wed, 29 Jul 2009 00:34:51 PDT

Das sechste .NET-Stammtisch Treffen findet mit Thomas Schissler und folgendem Thema statt:

Überblick über VSTS 2010.

Mit Visual Studio Team System 2010 bring Microsoft eine neue Generation seiner Entwicklungsplattform auf den Markt.

Neben einer großen Anzahl von Verbesserungen bring VSTS 2010 und das Backendsystem TFS 2010 auch völlig neue Funktionen und Möglichkeiten mit. Der Vortrag beleuchtet die verschiedenen Bereiche und stellt jeweils die wichtigsten Neuerungen vor. Diese werden mit verschiedenen Praxisbeispielen plastisch erläutert.

Thomas ist Leiter die Software-Entwicklung bei der Artiso AG in Ulm, Gründungsmitglied und Team-Leader der .NET Developer-Group Ulm und MVP für den Bereich Team System. Desweiteren ist Thomas viel als Sprecher auf großen Konferenzen und in User Group unterwegs. Das Weblog von Thomas, mit vielen Beiträgen zum Thema VSTS, ist unter folgender URL zu finden: http://www.artiso.com/problog/

Änderung im Ablauf der Veranstaltungen
Wir halten es in Zukunft so, dass es bei jedem Treffen nur einen Vortrag gibt, anschließend jedoch genügend Zeit bleibt um bei einem Bierchen darüber zu diskutieren, damit die Teilnehmer auch aktiv werden und die Sprechern Feedback empfangen und zusätzliche Fragen beantworten können.

Jan Welker über dotnet-kicks.de

Jürgen Gutsch — Tue, 28 Jul 2009 05:53:58 PDT

So, so… Da hat Dariusz Paris also auch den Jan Welker beim .NET Open Space Süd erwischt und interviewt ihn hier zu dotnet-kicks.de. (Übrigens war der Raum in dem das Interview gemacht wurde, während dem .NET Open Space Süd, der beliebtesten Raum der artiso AG. Wegen der roten Sessel natürlich.)

Das Ergebnis ist nun hier auf dem Blog von Dariusz zu sehen:
Community: Jan Welker über donet-kicks.de

Stefan Lieser über Clean Code Developer

Jürgen Gutsch — Tue, 28 Jul 2009 00:42:00 PDT

Beim .NET Open Space Süd waren unter anderem auch Stefan Lieser und von Microsoft Dariusz Paris anwesend. Interessant war zu sehen wie sich Dariusz sowohl eine Kamera als auch den Stefan krallte, um vor der Türe der artiso AG ein interview zu führen.

Das Ergebnis ist nun hier auf dem Blog von Dariusz zu sehen:
Community: Stefan Lieser über Clean Code Developer

Die Clean Code Developer Initiative

Jürgen Gutsch — Thu, 16 Jul 2009 00:09:00 PDT

Stefan Lieser und Ralf Westphal haben vor einiger Zeit die Clean Code Developer Initiative gestartet, die “Prinzipien, Regeln und Praktiken für bessere Software” aufstellt und vermittelt. Das ziel der Beiden ist es die Softwarequalität zu steigern und die Professionalität von Softwareentwicklern zu fördern. Die Regeln und Praktiken basieren auf dem Buch Clean Code von Robert C. Martin.

Clean Code nach Robert C. Martin kann jeder machen. Es erfordert allerdings ein radikales Umdenken, was aber aufgrund der provokanten Art von “Uncle Bob” relativ einfach fällt. Uncle Bob stößt einen praktisch mit der Nase in den eigenen Mist. Beim Lesen des Buches (liest sich übrigens fast wie ein Roman und sorgt - auf englisch gelesen – für einige Lacher) gibt es einen Aha-Effekt nach dem anderen.

Mir ist allerdings erst beim .NET Open Space Süd klar geworden, dass das Buch alleine nur dann was bringt, wenn man ganz alleine im stillen Kämmerlein vor sich hin entwickelt. Es ist unwahrscheinlich das es in einem größeren Team von jedem gelesen wird. Es ist genauso unwahrscheinlich, dass es von jedem im Team gleichermaßen interpretiert und eingehalten wird.

Um Clean Code nun einem größeren Team zu vermitteln, muss zuerst Interesse dafür geweckt werden. Es muss darüber geredet werden, es muss diskutiert werden. Clean Code im Team durchzusetzen ist ein längerer Prozess. Nicht jeder ist auf Anhieb bereit so stark umzudenken und so anders zu arbeiten. Wenn man Jahre lang schlechten Code entwickelt hat ist es schwierig die Regeln und Praktiken sofort anzuwenden oder sich überhaupt mit den Regeln und Praktiken anzufreunden.

Dabei hilft nun die Clean Code Developer Initiative. Mit Hilfe der Armbänder wird auch der das Interesse und somit ein Dialog angeregt. Entwickler kommen so mit der Initiative in Berührung, lesen die Prinzipien, Regeln und Praktiken, freunden sich damit an und fangen ans selber die Regeln zu berücksichtigen.

Was einen Clean Code Developer ausmacht kann hier nachgelesen werden: Wer ist ein Clean Code Developer (CCD)?

Das Wiki der Clean Code Developer Initiative: http://clean-code-developer.de/

Und hier nochmal das Buch Clean Code von Robert C. Martin

Das .NET Open Space Süd 2009 ist vorbei :-(

Jürgen Gutsch — Tue, 14 Jul 2009 01:03:00 PDT

Am Wochenende (11.07. und 12.07.) fand in der Nähe von Blaustein, bei Ulm, das erste .NET Open Space Süd statt. Die beiden Organisatoren Alexander Zeitler und Thomas Schissler hatten sich mächtig ins Zeug gelegt um uns die perfekte Umgebung für das Open Space zu liefern.

Ein besonderer Dank geht auch an den SV Arnegg, der für die komplette Bewirtung und die abendliche Unterhaltung bei der Party gesorgt hat und uns das Clubheim für das Mittagessen und die Party zur Verfügung gestellt hat. Es ist einfach auch eine geniale Idee den lokalen Sportverein in so eine Veranstaltung einzubinden.

Anders als auf herkömmlichen Konferenzen, waren in den zwei Tagen alle Anwesenden selber für das Programm und die Themen verantwortlich. Auf diese Art kann ein .NET Open Space nur ein voller Erfolg sein. Jeder bringt Themen ein, die ihn interessieren oder zu denen er was beitragen kann. So kam ein bunt gemischtes Programm zu fast allen wichtigen .NET-Themen und .NET-Technologien, aber auch zur allgemeinen Architektur zusammen.

Zusätzlich zu dem Programm war es sehr spannend, die Prominenz der .NET Community mal selber persönlich kennen zu lernen. Aber auch mit allen anderen ergaben sich anregende Diskussionen. Wer da war kann man in der Teilnehmerliste sehen.

Insgesamt hat es sehr viel Spaß gemacht und sollte 2010 auf jeden Fall wiederholt werden. Ich selber habe viele neue Ideen, Ansichten und Anregungen mit nach Hause genommen und bin sicher, dass es beim nächsten Mal wieder so wird :-)

Ach so: Die Bilder oben sind übrigens von Peter geklaut der natürlich auch mit von der Partie war. Mehr Bilder gibt es hier:

Auch dabei waren übrigens: Alex, Albert, Jan, Thomas, Bernd und viele mehr

PS: Habe mich dann doch zu einem “Clean Code Developer (CCD)”, á la Stefan Lieser und Ralf Westphal, “bekehren” lassen ;-) Einfach weil es auf diese Art einfacher ist, “Clean Code” auch an Anderen weiter zu vermitteln. Reden alleine Hilft nicht immer, man muss es auch “vorleben”. Werd mir dann mal so schnell wie möglich die Armbänder und das T-Shirt besorgen müssen :-)

Ressourcen aus externen Libraries im Markup ausgeben

Jürgen Gutsch — Mon, 29 Jun 2009 01:43:00 PDT

Bei großen Projekten kann es unter Umständen Sinn machen, alle String-Ressourcen in eine separate Library auszulagern. Das Problem ist dann nur, dass diese Ressourcen nicht mehr so einfach über die ASP.NET Markup angesprochen werden können.

Die Lösung gibt es mit einem eigenen ExpressionBuilder, mit dem es möglich ist einen eigenen ASP.NET Ausdruck zu schreiben um auf die externen Ressourcen zu zu greifen.

<%$ ExternalResources: General, LoginPageTitle %>

Um den Ausdruck von eventuellen internen Ressourcen auseinander zu halten habe ich den ExpressionPrefix “ExternalResources” genannt.

Die Struktur des xpressionBuilder sieht bei mir wie folgt aus:

[ExpressionPrefix("ExternalResources")] public class ExternalResourcesExpressionBuilder: ExpressionBuilder { public override object ParseExpression( string expression, Type propertyType, ExpressionBuilderContext context) { } public override CodeExpression GetCodeExpression( BoundPropertyEntry entry, object parsedData, ExpressionBuilderContext context) { } }

die Methode ParseExpression nimmt den Ausdruck auseinander und gibt diesen in einem gewünschten Format als Object zurück. In meinem Fall habe ich mir eine kleine Hilfsklasse namens “ResourceExpression” gebaut:

classKey = null; string resourceKey = null; if(expression.Length != 0) { string[] strArray = expression.Split(new[] { ',' }); int length = strArray.Length; if(length > 2) { return null; } if(length == 1) { resourceKey = strArray[0].Trim(); } else { classKey = strArray[0].Trim(); resourceKey = strArray[1].Trim(); } } return new ResourceExpression { ClassKey = classKey, ResourceKey = resourceKey };

Die Hilfsklasse:

public class ResourceExpression { public string ClassKey { get; set; } public string ResourceKey { get; set; } }

In der Methode “GetCodeExpression” findet die eigentliche Arbeit statt. Hier wird der Ressource-String ermittelt und zurückgegeben. Theoretisch kann hier auch per WebService auf einen Übersetzungsdienst zu gegriffen werden.

Ich hole mir allerdings nur per Reflection den entsprechenden ResoourceManager über den ich den zurück zu gebenden Ressource-String ermittle:

ResourceExpression expression = (ResourceExpression)parsedData; ResourceManager resourceManager = new ResourceManager("Cobra.Web.Resources." + expression.ClassKey, Assembly.GetAssembly(typeof(Resources.General))) { IgnoreCase = true }; string outString = String.Empty; if(!string.IsNullOrEmpty(expression.ResourceKey)) { outString = resourceManager.GetString(expression.ResourceKey); } return new CodePrimitiveExpression(outString);

Zu guter Letzt, muss der ExpressionBuilder noch in Web.Config registriert werden:

<configuration> <system.web> <compilation> <expressionBuilders> <add expressionPrefix="ExternalResources" type="GO.Web.Library.ExternalResourcesExpressionBuilder"/> </expressionBuilders> </compilation> </system.web> </configuration>

Web Slices für den IE8 ganz einfach selber machen

Jürgen Gutsch — Mon, 29 Jun 2009 00:02:00 PDT

Am Wochenende hatte ich tatsächlich etwas Zeit, um mir mal die Web Slices für den IE8 genauer anzuschauen.

Interessant ist, wie einfach es ist ein Web Slice zu erstellen. Allerdings gibt es eine Stolperfalle über die man nicht unbedingt stolpern muss.

Ein Web Slice wird als HTML im HTML der Website definiert und erstellt. Definiert wird ein Web Slice über speziell vorgegebene CSS-Klassen. Diese Klassen können zur Formatierung genutzt werden, müssen aber nicht. Ich habe es einfach gemacht und gleich diese Klassen für die Formatierung genutzt.

Definiert wird ein Slice mit einem <div> mit der Klasse “hslice” und einer eindeutigen ID (die ID hält mehrere Slices auseinander)

<div class="hslice" id="baseslice"> <h2 class="entry-title">Mehr von Jürgen Gutsch</h2> <div class="entry-content"> </div> </div>

Innerhalb des Slices wird ein Titel definiert. Üblicherweise ein <h2> Element. Der Titel wird über die Klasse “entry-titel” definiert. Dieser Titel erscheint dann in der Favoritenleiste des IE8.

Der eigentliche Inhalt des Slices wird in einem <div> mit der Klasse “entry-content” erstellt und kann im Prinzip alles beinhalten, sogar dynamischen Inhalt von einer anderen Seite. Dazu wird im <div>-Element für den Inhalt einfach ein “href” mit dem Link zur Externen Ressource eingefügt.

Die eine Stolperfalle gibt es bei der Formatierung: Das CSS greift nur, wenn es auf die Klasse “entry-content” angewendet wird, also auf das <div> für den Inhalt. Nicht aber auf das übergeordnete Element. Zudem werden die Formatierungen vom Dokument übernommen. Diese müssen also ggf. überschrieben werden.

Ein Web Slice könnte dann z. B. so aussehen:

ein sehr guter Artikel zum Thema ist im MSDN-Magazine zu finden: http://msdn.microsoft.com/de-de/magazine/dd458804.aspx

Und auch im Blog von Klaus Bock:
http://blog.klaus-b.net/

OT: (Meine) Zukunft der Politik in Deutschland?

Jürgen Gutsch — Tue, 23 Jun 2009 00:50:23 PDT

Aus aktuellem Anlass wird es leider mal wieder Zeit etwas vom Thema abzuweichen. Ich denke aber dass auch ich mal ein paar Worte schreiben sollte, die hoffentlich nicht allen gefallen werden. Aus Rücksicht auf die Volltextsuche von ASP.NET Zone habe ich den Senf mal hier veröffentlicht: juergen.gutsch-online.de