Am 26.04.2012 um 19:00 Uhr (diesmal einen Stunde später als gewohnt wegen der Microsoft Visual Studio 11 Beta RoadShow, die am gleichen Tag stattfindet) findet das nächste Treffen der .NET Usergroup Karlsruhe (XING-Gruppe der .NET Usergroup Karlsruhe) statt.

Thema

Domain Driven Design durch die SRP Brille

Details zum Thema

Domain Driven Design (DDD) von Eric Evans hat inzwischen weite Beachtung gefunden. Immer noch sind Entwickler jedoch nicht ganz klar, wie denn Eric Evans´ Vorschläge implementiert werden sollten. Die Linie zwischen traditioneller Objektorientierung mit Domänenobjekten und DDD ist unscharf.

In diesem Vortrag zeigt Ralf Westphal, wie das Single Responsibility Principle (SRP) die Grenze schärfer ziehen helfen könnte. Durch die SRP-Brille betrachtet führen DDD-Konzepte wie Entität, Aggregat oder Service zu recht anderen Lösungen im Vergleich zur DDD Mainstream Literatur. Doch interessanterweise ergibt sich so eine womöglich saubere und fruchtbare Trennung zwischen Objektorientierung und DDD.

Über den Sprecher

Ralf Westphal ist freiberuflicher Berater, Projektbegleiter und Trainer für Themen rund um Softwarearchitektur und Teamorganisation. Er ist Autor von mehr als 450 Fachpublikationen. Mit Stefan Lieser hat er die Initiative "Clean Code Developer" gegründet und arbeitet als einer der clean-code-advisors.de.        

Teilnahme

Bitte meldet Euch wieder via XING an, die Location ist wieder DJK-Ost:

DJK-Ost
Friedrichstaler Allee 52
76131 Karlsruhe

Anfahrt: http://www.djk-ost.de/html/vereinsheim.html

Hinweis

Außerdem findet am 27.04., also am Tag nach dem UG-Treffen noch ein Tages-Workshop mit Stefan Lieser und Ralf Westphal unter dem Titel “SRPx - Single Responsibility Principle eXtreme” statt – die Zahl der Anmeldungen ist allerdings auf 10 Teilnehmer beschränkt und wir sind fast ausgebucht.

Jeder, der bereits an einem .NET Open Space teilgenommen hat, hat sich vermutlich schon mal gedacht:

Jetzt könnte ich einen Open Space brauchen, aber bis Karlsruhe oder Leipzig dauert es ja noch so lange…

So ging es auch mir vor kurzem wieder und dank Timur Zanagar und der Stadt Ludwigsburg findet nun am 20.04.2012 in Ludwigsburg der 1. Shorty Open Space statt (SOS).

Ziel des SOS ist es, im Rhytmus von ca. 3 Monaten “Mini Open Spaces” zu veranstalten, bei denen es weniger Teilnehmer gibt und die Gesamtdauer ca. 6-8 Stunden beträgt - das ganze erhebt keinen Anspruch darauf, die Ideal-Lösung zu sein - es ist ein Experiment, weil wir (d.h. Timur Zanagar, Hans-Peter Schelian, Frank Pfattheicher und ich ) uns einfach gerne häufiger austauschen möchten und dies nicht nur zur .NET, sondern auch mit dem berühmten “Blick über den Tellerrand” hinaus.

Die Teilnehmerzahl haben wir für den ersten Shorty Open Space auf 25 begrenzt.

Wir möchten, anders als bei klassischen .NET Open Spaces, die Themenfindung bereits im Vorfeld weitestgehend erledigen, damit wir am Tag des Open Spaces nicht viel Zeit verlieren.

Hierfür haben wir bei tricider ein Board für die Themenfindung eingerichtet (danke an Sascha Dittmann für den Tipp).

Die Bedienung ist sehr einfach: Einfach mit Facebook- oder Google-Account einloggen, voten oder ein neues Thema vorschlagen - that’s it:

Hier nun die “harten Fakten” zusammengefasst:

Wann: Freitag, den 20. April 2012 um 13:00 Uhr bis Open End

Wo: Im Film- und Medienzentrum Ludwigsburg (www.fmz.de) im Konferenzraum 1 und 2

Bitte meldet Euch über Lanyrd an, wenn Ihr teilnehmt und beteiligt Euch an der Session-Planung bei tricider.

Verpflegung: Wir haben uns überlegt, dass jeder selber seine "Pizza" zahlt und wir nur einen festen Zeitpunkt festlegen. Sprich vor der ersten Session Bestellungen annehmen und dann für einen bestimmten Zeitpunkt bestellen.

Die Teilnahme ist kostenlos.

Twitter: das offizielle Hash-Tag ist #sos1

Hier noch ein paar Impressionen vom FMZ:

When using JSON (especially when consuming it from JavaScript) it’s common to use lower case.

When returning JSON using ASP.NET Web API, the casing of the JSON generated by the formatters depends on the casing of your DTOs (you’re using DTOs, right?!) you’re returning using Web API.

In order to get always lower case JSON, the simplest way is to use the new JsonMediaTypeFormatter in ASP.NET Web API or the JsonNetFormatter from the WebApiContrib project both of which use Newtonsoft.Json to (de-)serialize JSON .

Independent of which you’re using, you can create lowercase JSON by providing a LowercaseContractResolver which is injected to the JSON serialization process:

When using the official JsonMediaTypeFormatter, you can pass in the SerializerSettings this way:

When using the JsonNetFormatter from WebApiContrib, you can pass in the SerializerSettings this way:

The LowerCaseContractResolver has been posted by alexn on SO.

Am 29.03.2012 um 18:00 Uhr findet das nächste Treffen der .NET Usergroup Karlsruhe (XING-Gruppe der .NET Usergroup Karlsruhe) statt.

Thema

Think Big – Entwicklung skalierbarer Anwendungen mit Windows Azure

Details zum Thema

In vielen Anwendungsszenarien ist Big Data und Big Processing ein wichtiges Thema, sei es in der Energiewirtschaft, im Handel oder in der Logistik. Es fallen sehr viele Daten an, die von immer mehr Benutzern und Systemen konsumiert und ausgewertet werden wollen. Der Trend geht Richtung: Big!

Windows Azure ist die Cloud-Plattform von Microsoft und bietet Entwicklern eine Reihe von Diensten zum Erstellen von verteilten Anwendungen. Neben anderen Vorteilen haben Cloud-Anwendungen potentiell die Möglichkeit, mit den enorm steigenden Performanceanforderungen mit zu wachsen.

Cloud-Anwendungen sind jedoch nicht automatisch skalierbar und performant. Insbesondere die Datenhaltung, Abfragen an die Daten und die Konsistenz der Daten stellen eine Herausforderung dar. Skalierbare Anwendungen brauchen eine Antwort auf die Frage: Wie halte ich meine Daten und wie gehe ich mit dem Zustand der Anwendung um.

In diesem Vortrag werden verschiedene Architekturmuster und Technologien aufgezeigt, die helfen skalierbare Anwendungen zu entwickeln. Die Reise geht von NoSql und CAP-Theorem über Table-Storage und Sql-Azure zu den Queues und Topics sowie den Worker-Rollen.

Think Big!

Über den Sprecher

Aydin Mir Mohammadi
Als studierter Physiker und Vater von zwei Kindern ist er bei bluehands einer der .NET Virtuosen. Er ist der einzige gebürtige Karlsruher im Team, Gründer der .NET User Group in Karlsruhe und lehrt als Dozent für Datenbanken an der Berufsakademie Karlsruhe.         

Teilnahme

Bitte meldet Euch wieder via XING an, die Location ist wieder DJK-Ost:

DJK-Ost
Friedrichstaler Allee 52
76131 Karlsruhe

Anfahrt: http://www.djk-ost.de/html/vereinsheim.html

In this post I’ll show you two a ways to provide a RavenDb IDocumentSession to your ASP.NET Web API Controllers.

The ActionFilterAttribute approach

First approach is to use a ActionFilterAttribute.

Make sure you’re deriving from System.Web.Http.Filters.ActionFilterAttribute and not System.Web.Mvc.ActionFilterAttribute:

The RavenActionFilterAttribute relies on the DocumentStoreHolder Ayende introduced for his Raccoon Blog a while ago:

We also need a RavenController:

Finally we need to wire up our RavenActionFilter in Global.asax.cs:

Our concrete Controller may look like this:

Without ActionFilterAttribute

Don’t do this right now because if the usage of HttpContext.Current.Items.

Another way is not to use an ActionFilterAttribute.
First update your Global.asax.cs:

Then add a RavenApiController:

Then implement your concrete Controller:

...we're done!

Die Slides zu meinem ASP.NET Web API Round-Up bei der Online-Usergroup finden sich hier:

Samples finden sich hier.

Die Aufzeichnung ist ebenfalls online:

ASP.NET Web API Round Up from .NET Online User Group on Vimeo.

Today Microsoft presented and released ASP.NET MVC 4 Beta at  TechDays Belgium.

To me personally the most important improvement is the integration of the WCF Web API into the ASP.NET Stack.

One of the main reason for merging both has been the question “why two frameworks from Microsoft which allow us to create ReSTful APIs?”

Thus, the ASP.NET MVC developers now get the goodies from the WCF Web API.

Everything new?

Let’s take a look at how we do things now.

The most important change is the implementation of our own APIs themselfes:

Until now, we did it this way using WCF Web API::

Using ASP.NET Web API it looks like this:

As you can see, you’re implementing now a Controller also for APIs. But it does not derive from Controller as MVC Controllers do and there’s no common base class at all.

When looking at our code, you may ask: how does Web API know, which HTTP Methods should be mapped to which class methods?

ASP.NET Web API now uses Convention over Configuration already known from ASP.NET MVC, thus naming of the class method declares the HTTP method being used.

And by the way: Convention over Configuration also takes effect at the controllers: Controllers have to be inside the Controllers folder known from MVC.

Convention over Configuration…but

…there’s still a little piece of confiugration left. Let’s head over to the Global.asax.cs. That’s the place where ASP.NET Web API is (still) configured.

The only mandatory option that needs always to be configured, is the assignment of a route inside the route tables to our API controllers.

Here is another improvement: ASP.NET Web API now uses ASP.NET MVC Routing. But be careful: Route definitions don’t use MapRoute but MapHttpRoute instead:

The difference between default MVC route and the default Web API Route is that the action is not contained in our URIs (that’s were the convention comes in).

Thus, our API is available here:

http://localhost/api/customers

GET /customers/id, PUT, POST etc. work analogous.

If you want to implement more than one GET method on your web api class, you simply activate the action in you route definition:

Dependency Injection

Dependency Injection still works, of course - shown here using LightCore.

To give and receive...

Certainly, the improvements did not only come from WCF Web API to ASP.NET Web API, but also from ASP.NET MVC, e.g. Model Binding and Validation.

To use Validation you can use the already known Annotations like [Required] etc.:

To get it working, we need an ActionFilter:

The ActionFilter validates the incoming model (e..g. from POST) and creates a JSON object if there were  validation errors and sends them back to the client with a HTTP 400 (Bad request) status code.

At the client side we’re utilizing the response using jQuery AJAX POST:

Of course, on the client side it is necessary to include jQuery unobstrusive Validation Scripts and setting the HTML attributes:

ASP.NET Forms authentication now also is supported out of the box, but this will be part of another blog post.

Hosting

Besides the well known IIS Hosting it is now also possible to self host Web API inside your own process (which is not new for WCF but MVC):

In order to get self hosting working, System.Web.Http.SelfHost needs to be referenced.

That’s it for now to give you a short overview.

Microsoft hat heute auf den TechDays in Belgien die lang erwartete ASP.NET MVC 4 Beta vorgestellt und auch öffentlich zum Download bereitgestellt.

Die für mich wichtigste Neuerung ist die Integration der bisherigen WCF Web API in den ASP.NET Stack.

Einer der Hauptgründe für die Zusammenführung der beiden Projekte war die bisher berechtigte Frage nach der Koexistenz von zwei Frameworks von Microsoft, die beide das Erstellen von ReSTful Services erlauben - namentlich das bereits vorhandene ASP.NET MVC sowie die eben erwähnte und zum damaligen Zeitpunkt neu entwickelte WCF Web API.

Somit kommen den ASP.NET MVC Entwicklern nun die bereits implementierten Goodies der WCF Web API zugute.

Alles neu macht…der ApiController

Wie sieht das Ganze nun in der Praxis aus?

Die wichtigste Änderung ist die Implementierung einer API (oder auch Services, je nach Sprachgebrauch):

Bisher implentierte man eine API folgendermaßen:

Mit der ASP.NET Web API geschieht dies nun etwas anders:

Wie man sieht, wird nun für die APIs ebenfalls ein Controller implementiert, der jedoch nicht von Controller erbt, sondern von ApiController. Es gibt auch keine gemeinsame Basisklasse mit Controller.

Wenn man das Beispiel ansieht, taucht natürlich sofort eine weitere Frage auf: woher “weiß” die ASP.NET Web API, welches die Methoden für GET, POST, PUT etc. sind?

Hier greift nun das von ASP.NET MVC bekannte Prinzip “Convention over Configuration”, d.h. das Naming der Methode in der Klasse der API bestimmt auch deren HTTP Methode.

Übrigens gilt Conventention over Configuration auch bei den Controllern: Die API-Controller müssen ebenfalls im Controller-Ordner von ASP.NET MVC liegen.

Convention over Configuration…aber

…ein wenig Konfiguration gibt es doch noch - wechseln wir deshalb zur Global.asax.cs. Konfiguriert wird die ASP.NET Web API nach wie vor dort.

Die einzige Option, die grundlegend nötig ist, ist die Zuweisung einer Route in den Route Tables zu den ApiControllern.

Auch hier gibt es eine positive Neuerung: ASP.NET Web API nutzt nun das ASP.NET MVC Routing, allerdings erfolgt die Route-Definition nicht über MapRoute, sondern über MapHttpRoute:

Der Unterschied zur Default-Route von MVC ist der, dass die Action nicht explizit in der URI vorkommt (hier greift die genannte Konvention).

Somit ist unsere CustomersApi unter

http://localhost/api/customers

verfügbar - GET /customers/id, PUT, POST etc. funktionieren analog.

Möchte ich nun z.B. mehrere Get-Methoden implementieren, kann ich das über das Routing leicht ändern, indem ich einfach die Action einfach wieder mit in die Route aufnehme:

Dependency Injection

Natürlich funktioniert auch weiterhin Dependency Injection, hier wieder am Beispiel von LightCore.

Geben und nehmen...

Natürlich sind nicht nur Neuerungen der WCF Web API in die ASP.NET Web API eingeflossen, sondern Web API profitiert auch von ASP.NET MVC Features, z.B. dem Model Binding und der Validierung.

Für die Validierung können die gewohnten Annotations wie [Required] etc. verwendet werden:

Um die Validierung ans Arbeiten zu bekommen, ist nun noch ein ActionFilter nötig:

Der ActionFilter validiert das Model, welches z.B. per POST gesendet wurde und erzeugt im Fehlerfall ein JSON-Objekt, welches die Auflistung der Fehler enthält. Diese werden mit einem HTTP Status Code 400 (Bad Request) zurück an den Client geschickt.

Auf der Client-Seite werten wir das Ganze mit jQuery im POST-Request aus:

Voraussetzung ist natürlich das Einbinden der jQuery unobstrusive Validation Scripts und das Setzen der Entsprechenden Attribute im HTML-Code:

Ebenfalls unterstützt ist nun FormsAuthentication, dies wird allerdings Gegenstand eines eigenen Blog Posts sein.

Hosting

Neben dem bekannten Hosting in IIS (Express) ist es auch möglich, Web API in einem eigenen Prozess zu hosten:

Damit SelfHost funktioniert, muß System.Web.Http.SelfHost referenziert sein.

Das soll es als kurzer Überblick von meiner Seite zunächst gewesen sein.

Legacy Code Kata

Nachdem wir in den vergangenen Dojos immer auf der grünen Wiese angefangen haben, werden wir es in diesem Dojo mit einer existierenden Code Basis zu tun haben.

Wie so oft in der Realität, wird es auch hier die Aufgabe sein fremden Code zu erweitern. Trotzdem soll natürlich sicher gestellt sein, dass bestehende Funktionen immer noch wie erwartet funktionieren.

Ziel ist auch dieses mal wieder die Vertiefung der Fertigkeiten in der Zusammenarbeit als Team, Anwendung von TDD, Erkennen von Refactoring Patterns durch Babysteps und natürlich der Erfahrungsaustausch mit anderen Entwicklern.
Ansonsten gelten die üblichen Rahmenbedingungen:

• Lockere Atmosphäre
• Spaß am Coden
• Spaß mit gleichgesinnten Entwicklern haben
• Offen sein für Neues
• CleanCode
• TDD
• .NET oder auch jede andere Sprache (bitte Notebook mit entsprechender IDE mitbringen)

Das Mitbringen von Notebooks ist erwünscht, da wir uns in mehrere Teams aufteilen werden. Zumindest sollte eine Entwicklungsumgebung (Visual Studio, Eclipse, etc. ) installiert sein. Weitere Tools (NUnit, RhinoMocks, CodingDojoHelper, etc.) können wir dann gerne vor Ort verteilen.

Externe Tastaturen haben sich auch als sehr hilfreich erwiesen.

Anmeldung via XING.

Location:

DJK-Ost
Friedrichstaler Allee 52
76131 Karlsruhe

Beginn:
Di, 13.03.2012, 18:00

In Single Page Applications verwendet man häufig Hash-Bang Urls (was das ist, hat Robert hier beschrieben).

Setzt man nun anstelle des üblichen HomeControllers, der die Startseite (üblicherweise die Index View) rendert, eine statische default.htm Datei ein, will man natürlich die Hash-Bang Urls möglichst elegant und wie z.B. von twitter gewohnt in diesem Stil darstellen:

http://meineseite/#!/machwas

Durch die Verwendung der default.htm mit aktiviertem Default-Controller, müßte man das ganze allerdings so darstellen:

http://meineseite/default.htm#!/machwas

Leider funktioniert

http://meineseite/#!/machwas

zunächst nicht mehr (es erscheint die Index-Seite des HomeControllers oder ein 404, falls man den HomeController bereits gelöscht hat).

Der Grund liegt in den Route-Definitionen, die per Default in der Global.asax.cs definiert sind, genauer in der Definition eines Default-Controllers:

Entfernt man die Definition des Default Controllers

funktioniert der Aufruf von

http://meineseite/#!/machwas

wie gewünscht.

Natürlich kann man auch die Index-View des HomeControllers als Startseite für eine Single Page Application verwenden, was ich persönlich aber nicht (mehr) mache.