Just about .Net

Bei WPF bzw. Silverlight gibt es grundsätzlich die gleiche „Problematik“ wie bei Windows Forms bis .Net 4.0: Diagramme gehören einfach nicht zum Lieferumfang des Frameworks. Deshalb muss man in der Regel zu Dritt-Herstellern greifen, bindet die Charts von Windows Forms ein oder sucht sich kostenlose Alternativen.

In diesem Artikel soll es zunächst um die letztere Fassung gehen wobei in dem Fall zwischen Dynamic Data Display und dem WPF- bzw. Silverlight Toolkit gewählt werden kann. Nachfolgend werden die beiden Fassungen aus den Toolkits näher beschrieben. weiter lesen…

Eine der wichtigsten Gründe Prism einzusetzen ist die Möglichkeit die GUI in Regionen aufzuteilen. Jede dieser Regionen wird als Content-, Items- o.ä. Control repräsentiert und kann dann zur Laufzeit mit 1 (ContentControl) bis n (Items- oder TabControl) UserControls bestückt werden. Auf diese Weise wird die eigentliche Benutzeroberfläche lose gekoppelt und kann ohne größeren Aufwand an neue Anforderungen angepasst werden.

Ein immer wiederkehrendes Problem stellt für mich dabei die Nutzung des ItemsControl dar. Jenes zeigt die einzelnen Views in Form einer Liste an, was unter Umständen etwas langweilig und verwirrend wirken kann. Aus diesem Grund bietet es sich an, jene Views durch Überschriften oder Abgrenzungen voneinander zu trennen, aber wie kriegt man das hin? Kann man es evtl. auch ohne Prism verwenden? Und vor allem wie schafft man es mit möglichst wenig Aufwand? weiter lesen…

Es gibt diese Bugs über die Entwickler stundenlang philosophieren können und bei deren Erläuterung man reihenweise das Klatschen flacher Hände auf gerunzelten Stirnen vernimmt, weil man es ja eigentlich hätte wissen können. Nachfolgende Schilderungen gehören eindeutig in diese Kategorie…

weiter lesen…

Ich habe mich die letzten Tage ausgiebig mit der Klasse Lazy beschäftigt. Was diese alles kann will ich an der Stelle aber nicht ausgiebig erläutern, denn das habe ich hier schon einmal getan. Grundsätzlich sei nur gesagt, dass sie das verzögerte Instanziieren oder Initialisieren einer Klasse ermöglicht. Dabei bietet sie unter anderem die Möglichkeit eine Factory-Methode zu verwenden und genau diese kann uns so manches Problem bereiten.
weiter lesen…

Als ich nach Informationen gesucht habe um mein Post zum Thema Exceptions und “as” zu untermauern, bin ich in der MSDN auf zwei weitere Schlüsselworte gestoßen die ich noch nicht kannte: implicit und explicit

Diese Entdeckung hat mich schon etwas verwundert, sind beide doch seit .Net 2.0 Teil des Frameworks aber mir in den vergangenen Jahren noch nie über den Weg gelaufen. Woran das wohl liegt?

weiter lesen…

Heute widme ich mich mal wieder zwei Bestandteilen von .Net die es schon sehr lange gibt und deren Nutzung als Grundlagenwissen zu verstehen sind. Da mir recht häufig der “Missbrauch” dieser Dinge unterkommt, will ich hier die Vorteile und Nachteile etwas genauer beleuchten. Dabei geht es mir zunächst um das Schlüsselwort as und im Weiteren um Exceptions allgemein. weiter lesen…

I’ve spent the last weeks playing around with MEF which uses a feature of .Net 4.0 I didn’t know before: the Lazy class. A class which gives us a standardized, easy to use and thread safe way for implementing lazy instantiation.

Lazy instantiation describes a procedure of creating class instances on demand e.g. when accessing a property. The advantage is that you only invest resources like CPU time and memory if it is really necessary.
weiter lesen…

An english version of this post can be found here:
http://www.just-about.net/lazy-t-english

Im Zusammenhang mit MEF bin ich auf ein Feature von .Net 4.0 gestoßen, welches mir bisher nicht bekannt war. Genauer meine ich die Klasse Lazy<T>, welche ein standardisiertes und threadsicheres Vorgehen bei Lazy Instantiation bietet.

Lazy Instantiation beschreibt eine Art der Instatierung von Objekten, die erst zu dem Zeitpunkt ausgeführt wird wenn auf jene Objekte zugegriffen wird. Ein solches Vorgehen hat den Vorteil, dass unter Umständen Ressourcen gespart werden weil aufwändige Operationen nur wirklich dann angefordert werden wenn man sie benötigt.

weiter lesen…

Eine Sache die mich seit meinen (wenig umfangreichen) C Tagen nervt, sind Methoden die null Werte im Fehlerfall zurück geben. Mag sein, dass dies in einer Parallelwelt ohne Exceptionhandling seine Berechtigung hat. In Zeiten von Java und .NET ist so etwas aber antiquiert.

Ich weiß, dass sich schon eine ganze Reihe Blogs über das Thema ausgelassen haben, aber ich möchte an der Stelle einfach mal meinen Beitrag leisten, denn in meinem Arbeitsalltag stoße ich immer wieder darauf.
weiter lesen…

Update - Da diese Seite sehr stark frequentiert ist, möchte ich hier noch auf einen anderen Artikel hinweisen, der zeigt wie man einen Großteil der hier beschriebenen Probleme umgeht: http://www.just-about.net/der-freundliche-singleton

Googelt man Singletons und .NET wird man sehr schnell auf die folgende oder eine ähnliche Implementierung stoßen. Was in diesem Zusammenhang nicht erwähnt wird ist, dass auf diese Weise erstellte Singletons schnell zum Teufelswerk mutieren. Offensichtlich wird es, wenn man den obigen Suchbegriffen noch ein „evil“ hinzufügt. weiter lesen…