Es waren einmal ein paar Entwickler auf einem Microsoft WebCamp und es war die Idee geboren einer "Bullshit-Bingo-Online-Version” als Demo MVC Projekt. Alles Open Source natürlich. Unseren ersten Meilenstein haben wir erreicht... Ausprobieren unter www.bizzbingo.de / www.bizzbingo.com :)
Kurze Vorgeschichte
Auf dem WebCamp in München im Juni gab es am zweiten Tag eine Aufgabe zu meistern: Ein Demo MVC WebApp sollte entwickelt werden. Das Team was sich damals zusammengefunden hat - zu 4/5 Kollegen von mir und Torsten Hufsky kommt ebenfalls aus Dresden:
- Ken Kosmowski
- Tom Miller
- Oliver Guhr
- Torsten Hufsky
- und ich: Robert
Ehrlich gesagt kamen wir an diesem Tag nicht wirklich weit, aber die Ideen waren da - und auch das Projekt wurde auf Codeplex eingestellt. Die Idee dreht sich um "Bullshit/Buzzword Bingo” - nur als richtiges "Online Spiel”. Davon sind wir heute noch weit entfernt, aber es ist wie gesagt nur ein kleines Hobbyprojekt.
Nach dem WebCamp ist die Entwicklung etwas "eingeschlafen”, jedoch haben Ken und ich weitergebastelt um mal ein paar Techniken auszuprobieren.
Technik / Architektur
Als Datenspeicher dient eine Microsoft SQL Datenbank und als "Frontend Framework” für die Webkomponente ASP.NET MVC 3 - das ganze gehostet auf Windows Azure / SQL Azure. Als "Architektur” wollen wir uns an CQRS ranwagen.
Momentan ist es aber ungefähr so geworden - wir greifen (noch) auf eine Datenquelle zu, auch wenn die Idee eigentlich von CQRS war dass Queries auf eine Art "Cache” gehen.
Commands: Delete / Create / Update
Queries: Read
Hier mal ein paar Frameworks die wir einsetzen.
Applikations-Frameworks:
- ASP.NET MVC 3
- .NET 4.0
- Entity Framework für Datenzugriff
- Castle Windsor für IoC
- jQuery
- FEM CSS Grid
Test-Frameworks:
- NUnit
- Moq fürs Mocking
Build / Deployment:
- Powershell zum Deployen der SQL Scripts
- MSBuild
- Azure SDK
Sonstiges:
- Azure SDK wird aktuell noch in keinem Projekt genutzt, nur für das Hosting wie hier beschrieben.
- NDepend für Codeanalyse
- TeamCity als Buildserver
- Die Tests sind nach dem Vorbild von Thomas Bandts Blogpost entstanden - genauere Details wie wir Tests bei uns strukturieren folgen später, oder ihr schaut einfach selber nach ;).
Die Solution
Hier seht ihr die aktuelle Solution - den aktuellsten Stand findet ihr auch auf unserer Codeplex Seite.
Web = MVC Frontend
Queries / QueryHandlers = "Read” Befehle
Commands / CommandsHandlers = "Schreibende” Befehle
Data = Entity Framework & Mapping zum Model
Model = POCOs
Installer = IoC Konfiguration
Viel Zeit haben wir auch für die Tests aufgewendet. Kleine Besonderheit bei den "Unit Tests”:
- Data.Tests gehen gegen die Datenbank und testen die Repositories. Dabei wird wenn nötig automatisch die Datenbank über SQL Scripte, welche sich im Database Ordner befinden ausgeführt.
- IntegrationTests machen einen gesamten Systemtest und gehen von den Controllern aus - "WebTests” oder richtige "BrowserTests” sind es also nicht.
- Beide Tests erstellen zum Anfang einen Testdatenbank mit einem konsistentem Stand - aufbauend auf SQL Scripten.
Was kann die Website nun?
Besucher sehen ein zufällig generiertes Set an "Buzzwords”:
Wenn man nun in einem Meeting ist liegt es nun an dem Benutzer selber auf die Wörter zu klicken (ja, man kann bescheissen... muss man ja aber nicht.)
Sobald 4 Wörter in einer Reihe getroffen wurden hat man das Spiel gewonnen:
Momentan kann man nicht mehr machen... außer das die englisch und deutsch unterstützen. Man muss sich zudem nicht anmelden.
Warum wir einen Postback durchführen? Weil wir eigentlich noch mehr Ideen haben und richtig "Online Spielen” wollen. Ja - ein Postback ist heutzutage nicht mehr zeitgemäß, reicht uns momentan aber.
Source Code?
Wir nehmen CodePlex (und somit den TFS) als Source Control und arbeiten darauf. Den Source Code könnt ihr euch gerne hier anschauen.
Ausprobieren? Feedback?
Ausprobieren könnt ihr es hier. Feedback könnt ihr in unserem UserVoice Forum geben. Wir werden auf alle Fälle weiterbasteln und vielleicht kann es ja dem einen oder anderen auch helfen. Einige Blogposts werde sich bestimmt in Zukunft darum drehen und genauere Aspekte betrachten, wie z.B. Unit Testing oder wie wir Database Tests machen.
