Foundations for Professionals .NET Professionals im Profil guide to C# guidgen.de

Blog

Nutze den Augenblick
und teile der Welt mit, was Du zu sagen hast.

VSone: Singleton? Aber threadsicher!

Donnerstag, 25. Februar 2010, 20:05 Uhr
Permalink | Kommentare (0) | Kommentare als RSSRSS

Nachdem ich gestern Morgen – direkt nach der Keynote – meine erste Session auf der VSone in München gehalten habe, war ich gestern am späten Nachmittag mit einer weiteren Session an der Reihe. Unter dem Titel

Singleton? Aber threadsicher!

verbarg sich augenscheinlich lediglich die Frage, wie das Entwurfsmuster Singleton threadsicher umgesetzt wird – doch der Teufel steckt bei dieser Frage im Detail.

Nachdem ich vor 11 Teilnehmern zunächst in knappen Worten die Frage erläutert habe, warum die klassische Implementierung nicht threadsicher ist, habe ich einige verbreitete threadsichere oder vermeintlich threadsichere Varianten vorgestellt.

Was als scheinbar leichte Aufgabe begann, endete letztlich in der Analyse des vom C#-Compiler erzeugten MSIL-Codes, der Diskussion über eine Aspekte der Spezifikation von C# und der Erklärung einiger Spitzfindigkeiten innerhalb der .NET-Runtime.

Im Wesentlichen habe ich in der Session dabei die folgenden Punkte behandelt:

  • Singleton – klassisch
  • Singleton threadsicher – mit Locking
  • Singleton threadsicher – Double-checked locking idiom
  • Singleton threadsicher – ohne Locking
  • Verhalten von statischen Konstruktoren
  • Felder vs Eigenschaften

Besonders gefreut hat mich, dass ich mit einer ebensolchen Spitzfindigkeit innerhalb der Runtime von .NET ein nicht reproduzierbares, sporadisch auftretendes Problem im Code eines Teilnehmers lösen konnte.

Das erste Feedback zeigt mir, dass die Session auch den anderen Teilnehmern sehr gut gefallen hat – was mehr kann man sich wünschen?

VSone: XP – Extreme Programming für .NET-Entwickler

Mittwoch, 24. Februar 2010, 12:26 Uhr
Permalink | Kommentare (0) | Kommentare als RSSRSS

Heute und morgen findet im Neuen Forum am Deutschen Museum in München zum inzwischen sechsten Mal die VSone statt, unter deren Dach sich unter anderem auch die Advanced Developers Conference wiederfindet.

Dieses Jahr war ich erstmalig mit einem Vortrag auf der ADC vertreten. Im Rahmen meiner Session mit dem Titel

XP – Extreme Programming für .NET-Entwickler

habe ich XP als agile Methode vorgestellt, deren Werte und Techniken vorgestellt und die gängigen Kritikpunkte diskutiert. Als Kernelement der Session habe ich dabei auf die im agilen Manifest verankerten Werte zurückgegriffen, welche die Basis für sämtliche agilen Methoden bilden – sei es XP, Scrum, Chrystal oder eine beliebige andere agile Methode.

Wider mein persönliches Erwarten war die Session mit 34 Teilnehmern sehr gut besucht – dermaßen viel Interesse an XP hätte ich zunächst nicht erwartet. Im Wesentlichen habe ich in der Session die folgenden Punkte behandelt:

  • Was ist eine agile Methode?
  • Das agile Manifest
  • Werte von XP
  • Techniken von XP
  • Anforderungsmanagement
  • Gängige Kritikpunkte
  • XP + Scrum?

Insgesamt bin ich sehr zufrieden, wie alles gelaufen ist, und das Feedback, das ich bislang von den Teilnehmern erhalten habe, zeigt mir, dass die Session informativ und unterhaltsam zugleich war und positiv aufgenommen wurde.

.NET Reflector Pro

Freitag, 19. Februar 2010, 19:08 Uhr
Permalink | Kommentare (1) | Kommentare als RSSRSS

Von den zahlreichen Werkzeugen, die für die Softwareentwicklung auf Basis von .NET zur Verfügung stehen, sind nur einige wenige derart gelungen, dass sie ohne Wenn und Aber für wirklich jeden Entwickler empfehlenswert sind.

Zu diesen Werkzeugen zählen meiner Meinung nach unter anderem Resharper von JetBrains und .NET Reflector von Red Gate.

Resharper ist ein typisches Mausrad-Produkt: Eigentlich braucht man es nicht – aber nachdem man es für einige Weile genutzt hat, vermisst man es schmerzlich, wenn man dann ohne es auskommen muss. Erst in solchen Augenblicken spürt man, wie nützlich das Werkzeug ist, und wie nahtlos es sich in die eigene Arbeitsweise integriert.

.NET Reflector ist im Gegensatz zu Resharper bislang kein Addin für Visual Studio, sondern ein eigenständiges Produkt gewesen: Es ermöglicht das Disassemblieren und Rückübersetzen von Assemblies in zahlreiche Sprachen wie C#, Visual Basic oder auch MSIL.

Die Anwendungsgebiete sind vielfältig: Diese reichen von der Analyse von bestehendem Code zu Lernzwecken bis hin zur Fehlersuche in externen Assemblies. Zweifelsohne zählt .NET Reflector daher zu den Werkzeugen, die ein Entwickler früher oder später tatsächlich benötigt.

So praktisch .NET Reflector bislang war, so hakelig war auch die Bedienung: Da keine Integration in Visual Studio stattfand, musste .NET Reflector als eigenständiger Prozess nebenher laufen, die zu analysierenden Assemblies mussten per Hand gesucht und eingebunden werden, … nahtlose Integration sieht anders aus.

Vor einigen Tagen ist nun die neue Version 6 von .NET Reflector erschienen. Neben der Unterstützung von .NET 4.0 gibt es als neues Feature eine Integration in Visual Studio, die es ermöglicht, direkt aus dem Kontextmenü des Quellcodeeditors an die zugehörige Stelle innerhalb der disassemblierten Assembly zu springen.

Allein dieses Feature macht die Arbeit mit .NET Reflector bedeutend angenehmer und vor allem schneller, da aufwändige Suchen der Vergangenheit angehören. Aber – die neue Version bietet noch mehr: Erstmalig steht von .NET Reflector eine zweite Edition zur Verfügung: .NET Reflector Pro.

Die Webseite von Red Gate verspricht zu .NET Reflector Pro, dass es aus Visual Studio heraus möglich sein soll, Assemblies zu disassemblieren und diese disassemblierten Assemblies gemeinsam mit dem eigenen Code im Rahmen des Debuggers verwenden zu können.

Und – es funktioniert tatsächlich! .NET Reflector Pro verspricht nicht nur eine nahtlose Integration, tatsächlich ist es eine nahtlose Integration! So ist es mit .NET Reflector Pro problemlos möglich, gemeinsam mit eigenem Code die von dort verwendeten .NET-eigenen Assemblies Step-by-Step zu debuggen.

Kaum ein Produkt hat mich in den vergangenen Jahren derart begeistert wie .NET Reflector Pro – hinter einer schlichten und sehr kompakten Benutzeroberfläche verbirgt sich ein unglaubliches Potenzial.

Als einziger Wermutstropfen kann gelten, dass .NET Reflector Pro kostenpflichtig ist. Mit einem Preis von 145 Euro bewegt es sich aber – ebenso wie auch Resharper – in einem durchaus auch für private Entwickler erschwinglichen Rahmen, zudem muss man lange suchen, bis man ein weiteres Produkt mit einem ähnlichen, derart herausragenden Preis-Leistungs-Verhältnis findet.

.NET Professionals im Profil: Christian Wenz

Montag, 15. Februar 2010, 09:37 Uhr
Permalink | Kommentare (0) | Kommentare als RSSRSS

Christian Wenz ist Autor, Trainer und Berater mit Schwerpunkt Webentwicklung und Websicherheit sowie Mitbegründer der Hauser & Wenz Partnerschaftsgesellschaft. Als Buchautor veröffentlicht er seit fast zehn Jahren zu allen wichtigen Webthemen. Er hat zahlreiche Fachartikel verfasst und spricht regelmäßig auf Entwicklerkonferenzen im In- und Ausland. Als Teilhaber der Agentur Arrabiata Solutions GmbH leitet er Entwicklungsprojekte und führt Security-Audits durch. Sie erreichen ihn über seine Webseite.

Golo Roden: Christian, wie bist Du zur Softwareentwicklung gekommen? Wie und wann hast Du angefangen?

Christian Wenz: Indirekt hat mich mein Vater dazu gebracht. Er war Richter und hat auch Rechtspfleger ausgebildet. Unter anderem hat er da auch Zeugnisse erstellen müssen, in denen immer dieselben Textbausteine, abhängig von der Prüfungsnote, zum Einsatz kamen. Dies erledigte er irgendwann auf einem C128 mit PROTEXT. Mich hat da natürlich zunächst eher der ebenfalls eingebaute C64 interessiert.

Für Summer Games und Winter Games gingen mehrere Joysticks drauf. Letztendlich entwickelte ich aber auch ein Interesse für BASIC, und in der Schule gab es dann einen Informatikkurs, in dem mit Pascal gearbeitet worden ist. Programmieren machte mir Spaß, ich habe auch ein paarmal am Bundeswettbewerb für Informatik teilgenommen und so lag es nahe, das Hobby irgendwann in welcher Form auch immer zum Beruf zu machen.

Ich habe bereits nach der Schule als Entwickler gearbeitet; Informatik hatte ich dann später parallel studiert, weil ich gehört hatte, man müsse da nicht programmieren. Hat zu großen Teilen sogar gestimmt.

Golo Roden: Zusammen mit Tobias Hauser hast Du die Hauser & Wenz Partnerschaftsgesellschaft gegründet. Wie kam es dazu?

Christian Wenz: Tobias kenne ich aus der Schule. Bereits kurz danach haben wir mit einem dritten unserer Altersstufe eine kleine Webagentur gegründet und dort doch recht beachtliche Anwendungen auf die Beine gestellt. Währenddessen habe ich auch bei einer größeren Münchner Agentur angeheuert und habe dort ein paar Jahre lang an ziemlich großen Projekten gearbeitet und hatte am Ende richtig viel Verantwortung.

Parallel habe ich angefangen, erste Bücher und Artikel zu schreiben, und später auch Tobias mit diesem „Virus“ infiziert. Als ich 2002 einmal eine Pause vom aufreibenden Agenturalltag einlegen wollte und wir beide in Hinblick auf die Wissensvermittlung eh sehr erfolgreich waren, haben wir beschlossen, unsere Zusammenarbeit auch firmentechnisch auf eine solide Basis zu stellen.

Letztendlich sind wir aber 2005 wieder zurück auf die Projektschiene gewechselt und haben zusammen mit drei weiteren Partnern die Arrabiata Solutions GmbH gegründet. Unsere Themen sind das klassische Webagenturgeschäft, vom Design über die Implementierung bis hin zur Wartung, aber auch zahlreiche Beratungstätigkeiten, beispielsweise im RIA- oder SEO-Umfeld oder bei der Technologiewahl und Onlinestrategie.

Zu unseren Kunden zählen international ausgerichtete Mittelständler und Großkonzerne, die Aufgaben sind also stets sehr spannend. Meine aktuellen Aufgabengebiete sind Performanceoptimierung von Websites, LOB-Anwendungen im Browser, Web Application Security und mobile Anwendungen.

Golo Roden: Ein wesentliches Merkmal der IT ist, dass man beständig mit neuen Entwicklungen konfrontriert wird, und diesen folgen muss. Woher nimmst Du die Motivation, Dich quasi jeden Tag weiterzubilden und mit Neuem zu beschäftigen?

Christian Wenz: Ich arbeite gerne als Wissensvermittler. Dazu gehört es eben auch, immer über aktuelle Entwicklungen informiert zu sein um am Ball zu bleiben. Allerdings denke ich, dass ich ein eher mittelmäßiger Autodidakt bin. Ich muss mich also mit einer Sache schon beschäftigen, um später qualifiziert beurteilen zu können, ob sie mich oder meine Kunden weiter bringt oder nicht.

Das treibt mich natürlich immer wieder an, neues Wissen zu erarbeiten und nicht nur oberflächlich aufzusaugen. Außerdem sehe ich immer wieder, dass ich auch von den Erfahrungen der Vergangenheit profitieren kann.

Der Ajax-Boom ab 2005 kam mir insofern sehr gelegen, weil ich fast zehn Jahre vorher angefangen hatte, JavaScript einzusetzen. Bei der aktuellen Debatte rund um Silverlight finde ich unsere Projekterfahrung mit Flash sehr wertvoll, weil einige Ansätze und Einschränkungen freilich sehr ähnlich sind.

Golo Roden: Wenn sich ein Anfänger heute mit dem Thema Softwareentwicklung befassen will – welche Voraussetzungen sollte er Deiner Meinung nach dafür mitbringen, und was siehst Du als No-Go an?

Christian Wenz: Wichtig sind zum einen Neugier und auch der Wille, sich mit der Thematik zu beschäftigen. Gerade Programmiersprachen vergeben nur wenige Fehler, das Frustpotenzial ist hoch. Etwas komisch klingt vielleicht noch, dass man ein Faible für Mathematik und Logik haben sollte. Denn da verhält es sich ähnlich wie in der Programmierung: es gibt klare Regeln und abstraktes Denken ist gefordert.

Das soll natürlich nicht heißen, dass man für die Arbeit als Softwareentwickler den Beweis für den großen Fermatschen Satz nachvollziehen und täglich zwanzig Sudokus im Kopf lösen können sollte, das trifft auch beides auf mich nicht zu – aber wenn in der Schule der Dreisatz schon eine gewisse Hürde darstellte, hat man es auch als Entwickler schwer. Heutzutage ist es – allein schon dank der verfügbaren Dokumentation und Google – sehr einfach, ein irgendwie funktionierendes Programm zu schreiben. Im beruflichen Umfeld spielt die Softwarequalität jedoch eine große Rolle. Und dazu braucht man – meiner Meinung nach – ein „Händchen“ für Mathe & Co.

Golo Roden: Welche Rolle spielt Engagement in der Community für Anfänger – so wohl aus Deiner wie auch aus deren Sicht?

Christian Wenz: Ich denke, das hängt von der Art der Community ab. Beispiel Usergroups: Ich schaffe es ja leider viel zu selten zu den Usergroups denen ich angehöre, im .NET-Umfeld beispielsweise MunichDot.NET, aber die Diskussionen dort sind immer sehr spannend und vielschichtig – fast noch besser als auf Konferenzen. Ein blutiger Anfänger würde sich da allerdings eher schwer tun.

Geht es um Community im Sinne von Blogs, Websites, Wikis und Foren, dann sind diese natürlich heutzutage unverzichtbar. Wobei ich persönlich ganz ehrlich gestehen muss, dass ich zum Beispiel keine Blogreader-Software mehr verwende. Es gibt zu viele interessante Blogs, und ich habe zu wenig Zeit. Um nicht ein zu langes Backlog zu bekommen, besuche ich eine Reihe von Blogs unregelmäßig, aber dennoch häufig; für wichtige andere Neuerungen und Informationen verlasse ich mich auf Suchmaschinen und Twitter.

Wenn ich mich zurück erinnere, wie ich damals mit der Entwicklung angefangen habe und welche Recherche- und Hilfemöglichkeiten es damals gab, so bin ich schon sehr froh, was heute alles zur Verfügung steht. Da ich sehr viel aus der Community ziehe, halte ich es für selbstverständlich, ebenfalls beizutragen. Ich veröffentliche ziemlich viel, spreche sehr gerne vor Usergroups, auch über das INETA Speaker’s Bureau, organisiere und plane technische Veranstaltungen mit und trete natürlich vor allem auf Konferenzen auf. Das Schöne an funktionierenden Communitys: Nur wenige möchten nur bedienen; die meisten tragen nach ihren Möglichkeiten bei. So ist am Ende jeder etwas schlauer als vorher.

Golo Roden: Bei der Vielzahl an Technologien, die es heute gibt: Womit sollte ein Anfänger heutzutage anzufangen?

Christian Wenz: Zum Glück gibt es heutzutage für fast jede Sprache Möglichkeiten, kostenlos mit (fast) professionellen Mitteln zu entwickeln, seien es Microsofts Express Editions oder Eclipse samt seiner verschiedensten Plugins. Ich würde zunächst die Grundlagen der Programmierung lernen, am besten mit besonders einsteigerfreundlichen Sprachen, beispielsweise (Visual) Basic oder auch PHP.

Sobald die Grundlagen sitzen, würde ich mich recht schnell entscheiden, an welcher Art von Anwendungen ich im nächsten halben Jahr experimentieren will: Web? Fat Client? Mobile?

Dahingehend würde ich dann eine Sprache und/oder Technologie aussuchen. Ich denke, die „klassische“ Meinung ist, dass man mit einer „Lehrsprache“ wie etwa Pascal beginnen, alle wichtigen Grundlagen lernen und dann das Wissen auf jede beliebige andere Technologie übertragen sollte. Ich bin ja einen ähnlichen Weg gegangen.

Aber ich denke, es motiviert mehr, wenn man sein sich aufbauendes Wissen gleich in praktische Ergebnisse umsetzen kann. Übrigens konnte ich das damals sogar, denn Pascal war „in“ und Anwendungen eh meist nur Konsolenapplikationen.

Golo Roden: Neben .NET beschäftigst Du Dich auch mit PHP. Wo siehst Du die Stärken und Schwächen der jeweiligen Plattformen?

Christian Wenz: Typische Berater-Antwort: „Hängt davon ab“. Prinzipiell ist PHP natürlich von der Marktverbreitung her aktuell die unangefochtene Nummer 1. Beispiele wie Yahoo! und Facebook zeigen, dass sich Enterprise und PHP keineswegs ausschließen.

PHP ist sehr funktionsreich, performant, einsteigerfreundlich, wird durch eine extrem große Community unterstützt – und ist leider historisch gewachsen. ASP.NET ist etwa fünf Jahre jünger und mir gefällt der Steuerelementsansatz, der PHP im Wesentlichen fehlt. Allerdings gibt es auch einige webuntypische Einschränkungen und Eigenheiten, die gerade im klassischen Agenturalltag zu Stirnrunzeln führen.

Wir haben in beiden Technologien große Projekte erfolgreich umgesetzt. Mehr „Massengeschäft“ machen wir allerdings im PHP-Umfeld, insbesondere da es dort mehrere vernünftige freie Content-Management-Systeme gibt. Die Entscheidung welche Technologie es im Projekt letztendlich wird, hängt immer von mehreren Faktoren ab, unter anderem der bisherigen Systemstruktur des Kunden, dem Skillset der Entwickler, falls es nicht die eigenen sind, politisch motivierten Präferenzen und so weiter.

Golo Roden: Welchen Rat würdest Du einem Anfänger abschließend mit auf den Weg geben?

Christian Wenz: Neugierig sein. Kleine Schritte machen. Sich nicht von didaktisch miesem Lernmaterial und von zu anspruchsvollen Koryphäen frustrieren lassen – viele Veröffentlichungen haben ungeplant arg hohe Voraussetzungen. Und vielleicht nochmal das mit dem Dreisatz üben.

LightCore signiert

Dienstag, 9. Februar 2010, 22:39 Uhr
Permalink | Kommentare (1) | Kommentare als RSSRSS

Am 1. Januar 2010 hat Peter Bucher die erste Version seines neu entwickelten Microkernels LightCore veröffentlicht. Seitdem sind bereits wieder einige Features hinzugekommen, die allerdings derzeit nur in der Entwicklerversion zur Verfügung stehen, die als Quellcode aus dem zugehörigen Subversion-Repository abgerufen werden kann.

Nach wie vor halte ich LightCore für einen äußerst bemerkenswerten Microkernel und Dependency Injection-Container, auch die intensive Nutzung hat meiner Begeisterung keinen Abbruch getan – im Gegenteil.

Und dennoch – es gibt eine Kleinigkeit, die mich bislang gestört hat: Peter stellt LightCore lediglich als nicht-signierte Assemblies bereit. Das bedeutet, dass jeder, der wie ich eine signierte Variante benötigt, sich zunächst den Quellcode herunterladen, ihn anpassen und neu übersetzen muss.

Peter und ich haben daher beschlossen, dass ich zukünftig den jeweils aktuellen Stand von LightCore als signierte Version zur Verfügung stellen werde. Signiert sind dabei die folgenden drei Assemblies:

  • LightCore.dll
  • LightCore.Configuration.dll
  • LightCore.Integration.Web.dll

Nicht signiert ist die LightCore.CommonServiceLocator.dll, da diese von einer zumindest derzeit ebenfalls nicht signierten Assembly von Microsoft abhängt. Da es in .NET aus Sicherheitsgründen nicht möglich ist, aus einer signierten Assembly auf eine nicht-signierte Assembly zu verweisen, kann die LightCore.CommonServiceLocator.dll vorerst nicht signiert werden.

Der Download der signierten Variante von LightCore findet sich als ZIP-Archiv unter http://www.goloroden.de/Downloads/LightCore.aspx, wobei darin ebenfalls die nicht-signierte vierte Assembly enthalten ist.

In den nächsten Tagen wird dieser Link dann auch auf der offiziellen Webseite von LightCore verfügbar sein, so dass auch zukünftig alle verfügbaren und offiziellen Downloads dort aufgelistet sind.

Felder vs Eigenschaften

Montag, 1. Februar 2010, 09:37 Uhr
Permalink | Kommentare (3) | Kommentare als RSSRSS

Am 13. Oktober 2008 haben Peter Bucher und ich unter dem Titel Noch Fragen, Bucher? Ja, Roden! angekündigt, jeweils zum ersten eines jeden Monats einen Kommentar zu einem vorab gemeinsam gewählten Thema verfassen zu wollen. Bisher sind in dieser Reihe folgende Kommentare erschienen:

Heute, am 1. Februar 2010, ist es nun wieder so weit, und unser Thema für diesen Monat lautet:

Felder vs Eigenschaften

So wohl Peter wie auch ich haben uns unabhängig voneinander im Vorfeld unsere Gedanken gemacht, wie wir diesem Thema gegenüberstehen. Peters Kommentar findet sich zeitgleich in seinem Blog, folgend nun mein Kommentar zu diesem Thema:

Im Gegensatz zu klassischen Sprachen wie C++ oder Java verfügt C# seit der ersten Version über das Konzept der Eigenschaften: Ein für den Entwickler leichtgewichtiges und syntaktisch komfortables Konzept zum kontrollierten Zugriff auf Felder.

Gerade im Vergleich zu den in den genannten Sprachen üblichen zahlreichen Get- und Set-Methoden, die zum Zugriff auf Felder notwendig sind, bieten Eigenschaften einen enormen Vorteil, insbesondere im Hinblick auf die einfachere Lesbarkeit und damit auch bessere Verständlichkeit von Code.

Allerdings wird – beispielsweise in reinen Datenklassen – für den Zugriff auf Felder kein aufwändiger Zugriff benötigt, so dass die Definition einer Eigenschaft in der Regel zum einen immer nach dem gleichen Schema abläuft, zum anderen aber auch syntaktisch aufwändig und redundant ist.

Diesem Umstand trägt C# seit der Version 3.0 mit automatisch implementierten Eigenschaften Rechnungen, wodurch bereits deutlich weniger Code zu schreiben ist – allerdings immer noch deutlich mehr, als für ein Feld, das mit dem Zugriffsmodifizierer public ausgestattet wird.

Nun könnte man meinen, dass man an Stelle einer ohnehin leeren Eigenschaft durchaus ein öffentliches Feld verwenden könnte – doch es gibt einige Gründe, warum man dies unterlassen sollte:

  • MSIL-Code: Felder und Eigenschaften werden in unterschiedlichen MSIL-Code übersetzt, sind also binär nicht kompatibel zueinander. Im Nachhinein lässt sich ein Feld also nicht ohne weiteres durch eine gleichnamige Eigenschaft ersetzen, ohne abhängigen Code – beispielsweise in anderen Assemblies – zu brechen.
  • Referenzparameter: Felder können im Gegensatz zu Eigenschaften einer Methode als Referenzparameter übergeben werden. Deshalb kann ein Ersetzen eines Feldes durch eine Eigenschaft dazu führen, dass Methodenaufrufe nicht mehr kompiliert werden können, bei denen die Übersetzung zuvor ohne weiteres möglich war.
  • Reflection: Die Arbeit mit Feldern und Eigenschaften gestaltet sich per Reflection unterschiedlich, so dass ein Ersatz eines Feldes durch eine Eigenschaft ebenfalls wiederum abhängigen Code brechen könnte.
  • OOP: Es widerspricht dem objektorientierten Konzept der Informationskapselung, Felder als nicht-private zu markieren.
  • Debugger: Eigenschaften ermöglichen das Setzen eines Haltepunktes beim Auslesen beziehungsweise Schreiben, für Felder ist dies nicht möglich.
  • Datenbindung: Eigenschaften können im Gegensatz zu Feldern für die Datenbindung an Steuerelemente herangezogen werden.

Kurzum: Felder sollten ausschließlich mit dem Zugriffsmodifizierer private versehen werden, für alle anderen Anforderungen sind Eigenschaften in jedem Fall die bessere Wahl.