-> Praesentation downloaden.

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

Als erstes benötigen wir eine kleine Helfer Klasse:

public class BooleanVisibilityValueConverter : IValueConverter
{
    public object Convert(object value, Type targetType, object parameter, CultureInfo culture)
    {
        if (value != null)
        {
            if (((bool)value) == true)
                return Visibility.Visible;
            else
                return Visibility.Collapsed;
        }

        return Visibility.Collapsed;
    }

    public object ConvertBack(object value, Type targetType, object parameter, CultureInfo culture)
    {

        throw new Exception("The method or operation is not implemented.");

    }
}

Diese Klasse müssen wir im der entsprechenden xaml Datei per clr-namespace import verfügbar machen.

Danach setzen wir dies als Resource in einer unseren Controls/Window/Page/UserControl(whatever), hier zum Beispiel ein Grid.

<Grid.Resources>
    <helper:BooleanVisibilityValueConverter x:Key="BoolToVisible" />
</Grid.Resources>

Nun können wir diesen Helfer verwenden:

<CheckBox Name="EMailNotification" Content="E-Mail benutzen" />
<TextBox Visibility="{Binding ElementName=EMailNotification, Path=IsChecked, Converter={StaticResource BoolToVisible}}" />

Sollte die Checkbox nicht gesetzt sein, wird die Textbox nicht angezeigt. Sollte die Checkbox nun angeklickt werden wird auch die Textbox angezeigt.

Ich wünsche viel Spaß damit

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

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

1. Statische Links (auf das wesentliche gekürtzt, Quellcode ist selbsterklährend)

<HyperlinkButton NavigateUri="/Verzeichnis/meinWindow.xaml" />

Wie kann ich nun Paramter übergeben?

<HyperlinkButton NavigateUri="/Verzeichnis/meinWindow.xaml?ParamterKey=ParanterValue" />

Alt bekannt oder? Das auslesen dieses Paramters in der aufgerufenen View könnte so aussehen:

protected override void OnNavigatedTo(System.Windows.Navigation.NavigationEventArgs e)
{
base.OnNavigatedTo(e);
var paramter = NavigationContext.QueryString["ParamterKey"];

// Do something
}

Wir überschreiben einfach OnNavigatedTo. Danach könnnen wir auf den NavigatedContext zugreifen.

2. Navigation über Routen.

Dies kennt man eigentlich schon aus anderen Webprojekten wie CakePHP, RoR etc pp. Wir benötigen als sowas wie ein UriMapping. Dieses wird überlichweise in der App.xaml angelegt. Was wir in der App.xaml jedoch als erstes anlegen müssen ist ein Namespace der auf System.Windows.Navigation gesetzt wird.

xmlns:nav="clr-namespace:System.Windows.Navigation;assembly=Microsoft.Phone"

Und hier das Mapping, ist eigentlich selbsterklährend und man könnte es natürlich noch ein bisschen aufbohren .

<Application.RootVisual>
<phone:PhoneApplicationFrame x:Name="RootFrame" Source="/MainPage.xaml">
    <phone:PhoneApplicationFrame.UriMapper>
        <nav:UriMapper>
            <nav:UriMapper.UriMappings>
                <nav:UriMapping Uri="/Verzeichnis/{MyParamterKey}"
                                MappedUri="/Verzeichnis/MeineView.xaml?MyParameterKey={MyParamterKey}" />
            </nav:UriMapper.UriMappings>
        </nav:UriMapper>
    </phone:PhoneApplicationFrame.UriMapper>
</phone:PhoneApplicationFrame>
</Application.RootVisual>

Nun können wir den Hyperlink etwas umschreiben und unsere Route benutzen.

<HyperlinkButton NavigateUri="/Verzeichnis/MeinParaterValue" />

3. Navigation über den NavigationService

Dies ist ziemlich easy, als beispiel dient mir hier ein Button aus der ApplicationBar der ein event auslöst.

private void appbar_AddWishList_Click(object sender, System.EventArgs e)
{
    NavigationService.Navigate(new Uri("/View/WishListView.xaml", UriKind.Relative));
}

Das war es auch schon.
Weiterhin viel Erfolg beim entwickeln

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

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>

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.

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

Was ist Multithreading? Dazu müssen wir erst einmal wissen, was ein Prozess und was ein Thread ist.

Einen Prozess kennen wir alle, zumindest wenn wir mal einen Blick in den Taskmanager von Windows geschaut haben oder den Befehl „ps“ in einer Unix Shell ausgeführt haben.

Ein Prozess ist also nichts weiter als die laufende Instanz einer Anwendung. Jeder Prozess verfügt über seinen eigenen Adressraum und Ressourcen. Der Prozess selbst führt kein Code aus, denn er besitzt eine Menge >= 1 von Threads. Sollte der letzte Thread abgeschlossen sein, dann wird der Prozess beendet.  Das bedeutet natürlich, dass ein Prozess mindestens einen Thread besitzt.

Als einen Thread bezeichnet man im Grunde einen Ausführungsstrom innerhalb eines Prozesses. Er arbeitet Code ab und hat er das abgeschlossen, wird er beendet.

In .NET gibt es immer einen ganz besonderen Thread. Der sogenannte Main-Thread. Diesen Thread können wir uns nicht entziehen. Für jede Anwendung mit einer Main Methode wird ein Main- Thread erstellt. Sollte die Main Methode abgearbeitet sein, dann endet im Normalfall nicht nur unsere Anwendung sondern natürlich als erstes der Main-Thread -> und dann der Prozess in dem der Thread zugewiesen war.

Bei einem Singel-Thread Anwendung war es oftmals so, dass der Anwender nicht genau wusste was die Anwendung denn nun gerade genau tat? Lebt die Anwendung noch?  Vielleicht ist die Instanz der Anwendung ja schon tot. Wenn wir nun mehrere Threads hätten, könnten wir einen „Observer“ Thread dem Prozess hinzufügen, dieser überwacht und beobachtet die Aktionen des Main-Threads und Informiert den Anwender.

Kommen wir zu eigentlichen Frage zurück, was ist Multithreading denn nun? Ist Multithreading = Multitasking? Nein ist es nicht. Multitasking bezeichnet eigentlich die Fähigkeit, mehrere Tasks gleichzeitig auszuführen. Dies kann natürlich bei einem 1 Kern Prozessor nicht funktionieren, da dort die Rechenleistung nicht so einfach geteilt werden kann. Deswegen wechselt die CPU jeweils von Task zu Task um den User das Gefühl zu geben es würde gleichzeitig passieren.

Multithreading hingegen, ist die “gleichzeitige” Abarbeitung von Ausführungsströmen (wie oben schon beschrieben).

Kommen wir nun aber mal zum lustigen Teil des ersten Workshops. Fangen wir also mit unseren ersten Multithread Anwendung. Zuerst benötigen wir natürlich theoretisches Wissen über die Werkzeuge die wir benötigen.  Da macht es uns das .NET Framework recht einfach, denn alles was wir vorerst an Werkzeugen benötigen liegt im Namensraum / Namespace von „System.Threading“.

Wir erstellen also als erstes eine “Consolen Application” und fügen den Namespace “System.Threading” ein.

using System;
using System.Threading;

Im nächsten Schritt bauen wir uns 2 Methoden die uns helfen soll, die Threading Funktionalität zu visualisieren.

static void Incrementer()
{
 for (int i = 0; i <= 1000; i++)
Console.WriteLine("Increment to:{0}", i);
}

static void Decrementer()
{
 for (int i = 1000; i >= 0; i--)
Console.WriteLine("Decrement to:{0}", i);
}

In der Main Methode erstellen wir nun unsere Threads. Beim Initialisieren der Threads müssen wir dem Thread mitteilen, welche die Start-Funktion  ist. Danach können wir mit “Start()” die Threads starten lassen, zum Schluss wird einfach nochmal einen ReadKey Commando ausgeführt, weil sonst der Main-Thread beendet wird. Und was das bedeutet wissen wir ja jetzt, der Prozess würde ebenfalls beendet und wir würden unsere Ausgaben auf der Konsole verlieren.

static void Main(string[] args)
 {
Thread th1 = new Thread(new ThreadStart(Incrementer));
Thread th2 = new Thread(new ThreadStart(Decrementer));

th1.Start();
th2.Start();

Console.ReadKey();
 }

Vielleicht wird sich der einer oder andere Gedacht haben, dass sich die Ausgabe vom Incrementer und Decrementer immer (nach jeder Operation) abwechselt. Aber wie wir sehen ist das nicht so. Unser Betriebssystem gewährt jedem Thread eine unterschiedlich lange Rechenzeit auf der CPU. Der Scheduler ist im Endeffekt der Entscheider. Er entscheidet anhand von freien Ressourcen wie lange der Thread die CPU nutzen darf.

Das war es auch schon mit dem ersten Teil der Serie. Ich denke wir haben nun schon mal ein gewisses Fundament und damit im 2. Teil weiter zumachen. Dort erwartet euch dann wesentlich mehr Entwicklung. Es dreht sich um die einzelnen “States” eines Threads, außerdem müssen wir über Paramater und ParamterizedThreads sprechen.

Mehr dazu dann in ca. 1 Woche.

Problemstellung: Wir müssen (hochperformant) herausfinden ob eine bestimmte Instanz die gesuchte Datenbank verwaltet oder nicht.

Es gibt für dieses Problem dutzende von Möglichkeiten, eine recht performante Methode möchte ich gerne hier vorstellen. Jede Instanz auf einem MS SQL Server hat eine sogenannte “Master Datenbank”. Diese enthält unter anderem Schema-Informationen über die verwalteten Datenbanken auf ihrer zugeordneten Instanz. Darüber hinaus findet man super praktische Stored Procedures für die Datenbankverwaltung. Kurz: Jeder sollte sich mal diese Datenbank und deren Funktionen genauer anschauen, es lohnt sich.

Zurück zu unserem eigentlich Aufgabestellung. Wir missen nun also, dass die Master Datenbank eine Tabelle besitzt, die voll mit Schema-/Meta- Informationen über die verwalteten Datenbanken besitzt. Wir müssen also nur noch prüfen, ob es diese Informationen für die gesuchte Datenbank gibt, wenn ja existiert die Datenbank, wenn nein existiert Sie nicht.

Der Knackpunkt hier ist, dass wir uns nicht auf die gesuchte Datenbank verbinden, sondern auf die Master Datenbank. Wenn wir das nicht täten und uns auf die gesuchte Datenbank verbinden würden und diese dann nicht vorhanden wäre, hätten wir unter anderem einen ConnectionTimeout von 15 Sekunden (default). Diesen ConnectionTimeout können wir recht einfach mit der Verbindung zu Master Datenbank umgehen. Daraus holen wir also unsere Performance.

Hier das Listings 1.

// Connection string beinhaltet als initialCatalog die master Datenbank
using (SqlConnection connection = new SqlConnection(connectionString))
{
    SqlCommand command = connection.CreateCommand();
    command.CommandText = "SELECT COUNT(sid) From sysdatabases where name = N'@CatalogName'";

    SqlParameter param = command.CreateParameter();
    param.ParameterName = "@CatalogName";
    param.Value = "Meine_Datenbankname";

    if (Convert.ToInt32(command.ExecuteScalar()) == 1)
        Console.WriteLine("Datenbank exestiert");
    else
        Console.WriteLine("Datenbank ist nicht vorhanden");
}

Das war es auch schon, wie man sieht heißt diese Tabelle “sysdatabases”. Am besten man testet mal das Query im SSMS (SQL Server Management Studio).

Viel Spaß beim benutzen.