jt_

Vielen Dank für die Teilnahme, es hat mir sehr viel Spaß gemacht. Wie versprochen hier die Präsentation im PDF Format.

-> Praesentation downloaden.

Sollten Sie noch Fragen haben, können Sie mir gerne eine E-Mail schicken an jan.teumer@googlemail.com

Es ist endlich da! Das Sync-Tool von google für Outlook 2010 (nur 32 Bit Fassung). Das Tool gibt es hier.

Heute ein kleiner Mini-Snippet, der aber sehr hilfreich sein kann. Es dreht sich um das binden von der visibility Eigenschaft bei Controls auf bspw. einer Checkbox bzw. deren Wert. Dies brauchte ich nun häuftiger bei der Windows Phone 7 Entwicklung, da der Platz recht knapp bemessen ist . Jedoch ist diese Methode genauso in Silverlight oder WPF lauffähig.

Die SDK rund um das Windows Phone 7 arbeitet bekanntweiser mit Silverlight 3 und dem .NET Framework. Diese Kombination bietet uns nun von Haus aus 3 Möglichkeiten um in einer App zu navigieren.

1. statische Links (nicht geroutet)
2. Navigation mittels Routen
3. Navigation mittels NavigationService

Die ersten beiden Varianten sind nur für Hyperlinks verfügbar.

Was ist ein Singleton? Singleton beschreibt ein Pattern (Entwurfsmuster) vom Typ Creational Pattern. Die Aufgabe dieses Pattern ist es, dass es nicht möglich sein soll mehr als ein Objekt einer (Singleton)Klasse zu erzeugen. Prinzipiell arbeitet diese Klasse wir eine statische Klasse, jedoch vereinfacht dieses Pattern die Entwicklung eben dieser statischen Klasse. Üblicherweise sind diese Klassen global verfügbar.

Wo findet man denn bspw. soche Singletons? Besonders häufig wird diese Pattern in den UnitOfWork Klassen, die für den DataAccess verwendet werden. Wenn wir für eine Anwendung bspw. das Entity Framework verwerden würden, könnte eine solche Methode ein read only Context handeln, denn der Context selbst ist nicht Thread Safe.

Wie sieht ein Singleton Pattern überlichweise aus?

1. private / protected Konstruktor
2. Getter für Instance.

In C# hat man mehrere Möglichkeiten, eine Stelle ich euch hier vor. Diese Variante ist Thread Safe.

public sealed class MySingleton
{
    // Thread safe!
    static readonly MySingleton instance = new MySingleton();

    static MySingleton() { }

    // use private or protected
    private MySingleton() { }

    // Gets the instance of MySingleton class
    public static MySingleton Instance
    {
        get
        {
            return instance;
        }
    }

    // Return the hashcode of the instance
    public int GetSingletonHashCode
    {
        get
        {
            return this.GetHashCode();
        }
    }
}

Protected Konstruktor macht in diesem Beispiel eigentlich keine Sinn, da die Klasse “sealed” ist (kann nicht weiter abgeleitet werden).
Vielleicht kann das ja der eine oder andere gebrauchen

Viel Spaß damit

Also ich muss zugeben, ich bin kein Designer. Außerdem kann ich sagen, dass WPF mir eigentlich vom Aufbau und den Möglichkeiten die es bietet sehr antut, sodass ich auch selbst mal was bauen kann .

Nichts desto trotz haben mich die Height/Witdh Angaben bei den Windows-Elementen teilweise nahe einem Nervenzusammenbruch gebracht. Eigentlich sollte man annehmen, dass „auto“ Breite/Weite das Window automatisch auf die Größe des Fenster in Bezug auf die Child-Elemente anpasst. Dem ist jedoch nicht so. Das Attribut „SizeToContent“ hilft dann einem dabei.

<Window x:Class="HardwareStoreGui.MainWindow"
        xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
        xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
        Title="MainWindow" Height="auto" Width="auto"
        SizeToContent="WidthAndHeight">

    <Grid />

</Window>

Manche haben Probleme das Entity Framework (1er Version aus .NET 3.5 SP1) in einer eigenen Assembly laufen zu lassen. Das Problem ist ein leerer ConnectionString im Konstruktor des Context-Objectes. Das Problem resultiert daraus, dass der Connection String aus der App.Config von dem Projekt wo auch die Entity Framework Implementierung sich befindet, nicht in die App.Config der Main Methode(Exe Projekt) geschrieben wird.

Lösung?

1. Entweder die beiden App.Configs mergen oder den ConnectionString in eine App.Config schreiben die sich bei der .exe befindet.
2. Schönere Methode ist wohl das intitialisieren des Context mit einem ConnectionString.

Bermerkung zur 2. Variante:  Netterweise bietet Microsoft für das erstellen des ConnectionString schon was an. Im Namespace “System.Data.EntityClient” in der .dll System.Data.Entity bietet “EntityConnectionStringBuilder” Klasse an.

Genaures wie immer auf MSDN.

In den nächsten Wochen starte ich eine kleine Serie über das Thema Multi-Threading. Dieses Serie soll einen einfachen Einstieg in das Thema bieten und die wichtigsten Aspekte erläutern.

Im ersten Teil Heute geht es um das theoretische Wissen und unsere erste Multi-Threading Anwendung.

Heute mal ein kleines “code snippet” im Zusammenhang mit dem Microsoft SQL Server.