Der Programmierer bei der Arbeit

Erste Schritte mit Oak: Ein anderer Ansatz

Ted Neward

Ted NewardWie ich im letzten Artikel erläutert habe, ist das Oak-Projekt ein Webframework, das dynamische Aspekte und Ansätze integriert, die gängige Bestandteile von eher auf dynamischen Sprachen basierenden Frameworks sind (beispielsweise Ruby on Rails oder eines der verschiedenen MVC-Webframeworks in Node.js, wie Express oder Tower). Oak basiert auf Microsoft .NET Framework und verwendet dynamische und Dynamic Language Runtime(DLR)-Teile von C#. Daher unterscheidet sich der Oak-Ansatz für die Entwicklung von Webanwendungen deutlich von dem Ansatz, den traditionelle ASP.NET MVC-Entwickler verwenden. Wie Sie letztes Mal feststellen konnten, reicht es aus diesem Grund nicht aus, Oak einfach nur von NuGet herunterzuladen, sondern es werden weitere Komponenten benötigt.

Vorausgesetzt, Sie haben den vorherigen Artikel gelesen (msdn.microsoft.com/magazine/dn451446), Tools heruntergeladen und installiert, Sidekick für kontinuierliche Builds gestartet und den Anfangsbuild auf Ihrem Computer ausgeführt (wie beschrieben in IIS Express auf Port 3000), ist es jetzt Zeit, mit der Entwicklung in Oak zu beginnen.

So fangen Sie an

Wenn Oak auf Ihrem Gerät nicht ausgeführt wird, geben Sie in der Befehlszeile „rake“ und „rake server“ ein, nur um sicherzustellen, dass alles in Ordnung ist. Starten Sie dann Sidekick, wenn es nicht schon ausgeführt wird, und rufen Sie im Browser „localhost:3000“ auf, wie in Abbildung 1 gezeigt.

Oak Project Help Window
Abbildung 1: Hilfefenster im Oak-Projekt

Wie das angezeigte Lernprogramm erkennen lässt, können Sie Oak anhand einer exemplarischen Vorgehensweise im Breadcrumbsstil erlernen. Bevor ich mit Oak fortfahre, werfen wir einen kurzen Blick auf die in Abbildung 2 gezeigte Projektstruktur.

Oak Project Structure in Visual Studio Solution Explorer
Abbildung 2: Oak-Projektstruktur im Visual Studio-Projektmappen-Explorer

Das Ausgangsprojekt umfasst zwei Projekte: das ASP.NET MVC-Projekt und das Projekt mit den Tests für die Projektmappe. Das MVC-Projekt ist eine herkömmliche ASP.NET MVC-App. Hier wurde der Oak-Ordner mit den Quelldateien hinzugefügt, aus denen der Oak-Teil des Projekts besteht. Dadurch wird es sehr einfach, beim Debuggen die Oak-Teile des Codes durchzugehen. Außerdem sind – im Geiste aller Open Source-Projekte – ggf. lokale Bearbeitungen möglich. Derzeit hat das Projekt keine Modelle, drei Controller und nur ein paar Ansichten. Doch wichtiger ist, dass es hier noch nicht viel Code gibt und daher die erste Anforderung an den Endpunkt den Fehler erzeugt, dass keine Ansicht „Index.cshtml“ (oder ähnlich) vorhanden ist. Der Oak-Bootstrapper schlägt zwei Schritte vor. Erstens erstellen Sie zwei neue Typen: „Blog“ und „Blogs“, eine Collection von Blog-Instanzen. Durch Aufrufen der Klasse „Blogs“ erhalten Sie einfachen, konventionsbasierten Zugriff auf die Blogs-Tabelle in der Datenbank:

public class Blogs : DynamicRepository
{
}
// This is a dynamic entity that represents the blog
public class Blog : DynamicModel
{
  public Blog() { }
  public Blog(object dto) : base(dto) { }
}

Zweitens sind einige Änderungen an „HomeController“ erforderlich, damit die Klasse auf unterschiedliche gesendete HTTP-Anforderungen antworten kann, wie in Abbildung 3 gezeigt.

Abbildung 3: Antworten auf unterschiedliche HTTP-Anforderungen

public class HomeController : Controller
{
  // Initialize the blog
  Blogs blogs = new Blogs();
  public ActionResult Index()
  {
    // Return all blogs from the database
    ViewBag.Blogs = blogs.All();
    return View();
  }
  // Controller action to save a blog
  [HttpPost]
  public ActionResult Index(dynamic @params)
  {
    dynamic blog = new Blog(@params);

Vieles davon wird ASP.NET-Entwicklern vertraut sein. Der wesentliche Unterschied besteht darin, dass durchweg eine Typisierung als dynamischer C#-Typ erfolgt, nicht als „Blog“ oder Instanzen von „Blogs“. Der Blog-Typ selbst hat keine Felder oder Eigenschaften. Für den Blogs-Typ – eine Aggregation von Blog-Instanzen – wird ebenfalls kein Code für Vorgänge deklariert, die häufig mit Collections verbunden werden, wie beispielsweise Einfügen, Entfernen, Auflisten oder Ersetzen.

Viel von dieser Leistung entspringt der Gemini-Bibliothek, einem Kernbestandteil des Oak-Projekts (und Thema meines Artikels vom August 2013, „Dynamisch entwickeln mit der Gemini-Bibliothek“ unter msdn.microsoft.com/magazine/dn342877). „Blog“ erweitert die DynamicModel-Basisklasse, was im Grunde bedeutet, dass Sie für diese programmieren können, ohne zuerst das Modell definieren zu müssen. Jedes Feld, auf das Sie in einer gegebenen Blog-Instanz verweisen, ist vorhanden, sogar wenn Sie nie zuvor darauf verwiesen haben. Das ist die Stärke der dynamischen Programmierung. „Blogs“ ist auch ein dynamisches Repository und weiß als solches bereits, wie DynamicModel-Objekte gespeichert und bearbeitet werden.

Sogar noch interessanter ist, dass Oak standardmäßig weiß, wie Blog-Instanzen in einer SQL-Tabelle (namens „Blogs“, was nicht weiter überrascht) gespeichert werden. Oak erstellt nicht nur bei der ersten Verwendung das Datenbankschema, sondern kann auch die Datenbank grundlegend mit beliebigen Startdaten füllen, die das System möglicherweise benötigt.

Wenn Sie eine Blog-Instanz erstellen, akzeptiert sie ein dynamisches Objekt als Parameter. Der Basisklassenkonstruktor weiß, wie er jedes der dynamisch definierten Felder/Eigenschaften in diesem Objekt durchgeht. Ebenso weiß die Blogs-Instanz, wie sie alle dynamisch definierten Felder/Eigenschaften einer Blog-Instanz durchläuft. Sie speichert sie in der Datenbank (im Aufruf von „blog.Insert“). Sie weiß außerdem, wie sie eine Blog-Instanz über das BlogId-Feld aus der Datenbank abruft. All dies wird durch den Code in Abbildung 3 gestützt, es ist kein zusätzlicher Modellcode erforderlich, oder zumindest noch nicht. (An dieser Stelle würden Sie möglichweise noch mehr hinzufügen, aber zum augenblicklichen Zeitpunkt ist einfach alles funktionsfähig.)

Nebenbei, falls Sie sich fragen, welches der @-Operator ist, denken Sie daran, dass „params“ in C# ein reserviertes Wort ist. Damit Sie es als akzeptierbaren Parameternamen verwenden können, müssen Sie ihm das @-Präfix voranstellen, damit der C#-Compiler es nicht als Schlüsselwort behandelt.

Nach der Bearbeitung von „HomeController.cs“ ist der nächste Schritt das Erstellen einer akzeptierbaren Ansicht, „Index.cshtml“, in einem Ordner „Home“ unter dem Ordner „View“. In dieser Ansicht werden die Ergebnisse der Arbeit des Controllers angezeigt, wie in Abbildung 4 gezeigt.

Abbildung 4: Erstellen der Ansicht

@{
  ViewBag.Title = "Index";
}
<h2>Hello World</h2>
<div>

Wenn diese Seite erfolgreich angezeigt wird, kommen Sie gut voran! Erstellen Sie jetzt einen Blog (versuchen Sie, Blogs mit doppelten Namen zu erstellen).

</div>
<br />
@using (Html.BeginForm()) 
{
  @Html.TextBox("Name")
  <input type="submit" value="create" />
}
@foreach (var blog in ViewBag.Blogs)
{
  <div>
    <pre>@blog</pre>
    <br />
    <div>
Almost there, you have comments listing; let's try to add one.
    </div>
    <br />
  </div>
}

Die Ansicht ist nicht einfach nur eine weitere ASP.NET-Ansicht. Erneut kommt der dynamische Charakter des Systems ins Spiel. Ein Name-Feld wird in keiner Blog-Instanz im Blog-Typ definiert, aber bei einer Übermittlung des Formulars oben in der Ansicht wird der Parameter „name=...“ an „HomeController“ übergeben. Dieser Controller übergibt anschließend das Name/Wert-Paar in der @params-Variable, die zum Initialisieren einer Blog-Instanz verwendet wird. Die Blog-Instanz verfügt nun über ein Feld bzw. eine Eigenschaft „Name“, ohne dass zusätzliche Arbeit Ihrerseits notwendig war.

Auf ganzer Linie kontinuierlich

Übrigens, wenn Sie diese Dateien auf Ihrem Computer gespeichert haben, werden Sie etwas Interessantes bemerken (siehe Abbildung 5).

Growl Notification Showing the Build Succeeded
Abbildung 5: Eine Growl-Benachrichtigung zeigt, dass der Build erfolgreich war

Zunächst einmal wird eine Benachrichtigung in der Ecke unten rechts eingeblendet. Diese stammt von Growl. Sie werden mit einem grünen Signal darüber informiert, dass der Build, der von der vorher von Ihnen gestarteten Sidekick-App ausgelöst wurde, erfolgreich ist. Wenn der Build aus irgendeinem Grund fehlschlägt, ist die Grafik links im Benachrichtigungsfenster rot, und die Konsolenausgabe wird in der Benachrichtigung angezeigt. Zweitens können Sie im Konsolenfenster, in dem Sidekick ausgeführt wird, erkennen, was passiert ist. Der Dateisystemwatcher im Verzeichnis „Blog“ hat erfasst, dass eine Quelldatei geändert wurde (da Sie sie gespeichert haben). Für Sidekick ist dies das Stichwort, um das Projekt neu zu erstellen.

Angenommen, dass die Dateien gespeichert sind und der Code korrekt ist, erhalten Sie durch erneutes Aufrufen von „localhost:3000“ das neue Ergebnis, wie in Abbildung 6 gezeigt.

Oak Cannot Make Bricks Without Clay
Abbildung 6: Ohne Ton kann Oak keine Ziegel brennen

Diesmal versucht Oak, eine Verbindung mit einer ausgeführten SQL Server-Instanz herzustellen, um Daten aus dieser Tabelle (der Tabelle „Blog“) abzurufen. Oak versucht automatisch, die Bestandteile der objektrelationalen Zuordnung (Object Relation Mapping, ORM) im Projekt für Sie zu verwalten. Auf diesen Aspekt werde ich im nächsten Artikel näher eingehen.

Ein anderer Stil

Wie Sie sehen, verwenden Sie mit Oak definitiv einen anderen Entwicklungsstil. Sie mussten an keiner Stelle etwas Komplizierteres in Visual Studio ausführen als eine Datei zu öffnen, deren Inhalte zu ändern und die neue Version zu speichern – und dem Projekt eine neue Datei hinzuzufügen. Sie mussten an keiner Stelle jemals einen Build starten, diesen in Visual Studio ausführen, den Server-Explorer zum Erstellen von Tabellen öffnen oder SQL Server-Skripte starten.

Falls erforderlich, steht Ihnen all das weiterhin zur Verfügung. Oak ist nur eine Schicht (und zwar eine ziemlich dünne), die über den herkömmlichen ASP.NET-Stapel gelegt wird. Diese Schicht ermöglicht allerdings ein Maß an schneller Entwicklung und Produktivität, das anderen, dynamischeren Umgebungen entspricht, ohne die Vorzüge aufzugeben, die Sie an der statisch typisierten Welt schätzen.

Oak bietet noch mehr Möglichkeiten, aber diese Themen werde ich in Zukunft erläutern.

Viel Spaß beim Programmieren!

Ted Neward , Geschäftsführer von Neward & Associates LLC, hat mehr als 100 Artikel geschrieben und als Autor und Mitautor ein Dutzend Bücher verfasst, darunter „Professional F# 2.0“ (Wrox 2010). Er ist ein F#-MVP und spricht auf Konferenzen in der ganzen Welt. Er berät und hilft regelmäßig – Sie können ihn unter ted@tedneward.com erreichen, wenn Sie möchten, dass er in Ihrem Team mitarbeitet, oder lesen Sie seinen Blog unter http://blogs.tedneward.com.

Unser Dank gilt dem folgenden technischen Experten für die Durchsicht dieses Artikels: Amir Rajan (Initiator des Oak-Projekts)