Vor einer ganze Weile habe ich über eine Idee geschrieben, die wir eine ganze Weile auch in einem Projekt so verfolgt haben. Ein anderes geniales Konzept, wo ich mir nicht ganz sicher war, war das Exception Handling. Nachdem ich beide Ideen in einem Projekt umgesetzt hatte, kommt jetzt mein Fazit: Keep it simple!
Mein kleines Projekt “ReadYou” kommt in winzigen Schritten vorwärts – allerdings mehr auch nicht. Grund hierfür ist meist, dass wenn man sich in ein Thema mal versucht einzulesen, man sofort auf zwei neue interessante Sachen stößt. So z.B. die Mockinggeschichte um meine UnitTests besser zu gestalten.
Architekturumgestaltung
Meine Grundsätzliche Architektur war so aufgebaut wie in diesem Blogpost beschrieben.
Durch das gute Feedback zu dem 3-Schichten Architektur Blogpost habe ich es nun grob so eingeteilt:
Mein Model liegt nun nicht mehr im Data rum, sondern ist theoretisch auf allen Schichten erreichbar und daher in einer eigenen DLL zu finden. Das Model besteht aus einfachen POCOs – die nichts anderes machen außer Daten halten.
Da ich möglichst flexibel bin und auch alles fein säuberlich testen kann, ist jede Schicht aufgeteilt in:
Bei Data ist natürlich genau dasselbe vorzufinden: Die Trennung zwischen den Interfaces und der eigentlichen Implementierung die ich vorgenommen habe.
Response & Request bei den Services
Als ich mein Interface für den BookService vorbereitet habe, habe ich überlegt, was ich alles für “Aufrufe” brauche:
public interface IBookService
{
IList<Book> GetBooks();
IList<Book> GetBooksByAuthor(Author author);
IList<Book> GetBooksByUser(User user);
IList<Book> GetBooksByTag(Tag tag);
IList<Book> GetBooksByCategory(Category cat);
....
}
Allerdings ist das nicht wirklich schön – mein Service hätte äußerst viele Methoden um Bücher ranzuholen. Einmal anhand des Autors, einmal nach Kategorie etc.
Komplexer wären noch Sachen wie: “GetBooksByCategoryAndUser” – heiei… für jeden Fall eine Methode zu schreiben, erscheint mir nicht sinnvoll.
Meine Lösung: Request & Response
Wie ein “WebService” geben meine Services auch Responses zurück und verlangen ein Request Objekt:
Diese Objekte habe ich in ReadYou.Service.Model hinterlegt – da sie nur im Service vorkommen, ich allerdings diese Definitionen und die Logik in seperaten DLLs trennen wollte:
Dabei leitet der “GetBooksRequest” von “BaseRequest” ab und beim Response genauso.
Durch dieses Objekt kann ich später genau mein “GetBooksRequest” definieren:
public class GetBooksRequest : BaseRequest
{
public Tag Tag { get; set; }
public Category Category { get; set; }
public User User { get; set; }
public Author Author { get; set; }
}
Jetzt könnte ich mir sowas wie “Gib mir alle Bücher vom Autor XYZ, des Users ABC mit der Kategory “Krimi”" – das erlaubt mir einige Freiheiten und sollte erweiterbar sein, falls mir wieder was neues einfällt.
Wie sieht das im Projekt aus?
Alles ist aufgeteilt – dabei fehlen allerdings noch UnitTests für den “Data” Teil und für die WebApp (die hier noch nicht zu sehen ist). Unter “Common” befinden sich nur ein paar Extensions die mir das leben erleichtern 
Mit dieser Ordnung bin ich gerade recht zufrieden – alles ist soweit getrennt und alles was Logik hat, hat auch ein Interface. Späße wie Dependency Injection und co. steht auch nichts im Wege.
Durch die Response / Request Sache bin ich später recht flexibel – auch wenn es etwas mehr Schreibaufwand ist.
Das wichtigste ist allerdings:
Wie seht ihr das? Ist die Idee mit den Response/Request Objekten vielleicht doch nicht so toll? Gebt einfach euer Feedback ab – den Code (sobald ich noch etwas weiter bin), werde ich auf Codeplex zur Verfügung stellen. Momentan ist diese Version noch nicht hochgeladen.
ScottGu hat in seinem Blog die neusten Informationen zur kommenden Preview 4 des ASP.NET MVC Frameworks bereitgestellt.
Mit dem “Preview 4″ kommen einige High-Level-Features hinzu:
Das eingebaute Membership-System soll später noch abstrahiert werden – sodass man auch sein eigenes System (ohne ein Membership-Provider zu schreiben) nutzen kann. Das ideale für mein ReadYou Projekt
Die neuen Features konnten bereits mit Preview 3 bereitgestellt werden – mit dieser Preview sollen einige nette Features der Allgemeinheit leicht zur Verfügung gestellt werden – auf die AJAX Funktionalität bin ich auch schon gespannt
Fazit: Nix weltbewegendes, aber eine gute Fortführung des Projekts um es später für viele leicht nutzbar zu machen
Mein letzter direkter “ReadYou” Post ist schon etwas länger her – meine Membership-Idee habe ich in einem HowTo mal verwirklicht, allerdings hatte ich bisher keine Gelegenheit mehr zu coden.
Authentication, Authorization & Personalization
Für mich persönlich war der Kommentar von Andre Loker ein Anstoß darüber nachzudenken, das Membership System komplett zu entfernen bzw. einfach meinen eigenen Provider zu schreiben. Die verschiedenen Tabellen vom Membership-System find ich recht “groß” und unübersichtlich.
Insbesondere passt aber das Membership-System nicht ganz in meine Architektur rein.
Gut, dass nicht nur ich so denke, sondern inzwischen auch Rob Conery zu diesem Ergebnis gekommen ist. Den Anstoß gab Ayende Rahien in dem 15 Teil vom MVC Storefront Screencast.
Inzwischen hat Rob den 16 Teil fertig gestellt – in diesem verwirft er das Membership-System und implementiert prototypisch OpenID.
Hinweis: Meine Anwendung wird stark an die Architektur von Rob angelehnt sein – ich hab dies bereits produktiv in einem Projekt eingesetzt und bin positiv überrascht wie gut dies geklappt hat
Die gesamte MVC Storefront Serie ist sehr sehenswert!
Robs Screencast endet bei dem Login mit OpenID – er erwähnt noch, dass er sich nun auch Gedanken macht, wie er die OpenID tatsächlich an einen User knüpfen kann. Selbe Gedanken beschäftigen mich ebenfalls schon eine Weile (und insbesondere habe ich ja noch den mutigen Vorschlag gehabt Windows Live ID mit zu unterstützen 
).
Was es nicht heute alles gibt
Ich muss zugeben, dass ich früher mir nicht so einen großen Kopf um das Usersystem an sich gemacht hatte – da wird das Passwort und ein Loginname vergeben und gut ist.
Allerdings bin ich der Meinung, dass hier einige große Veränderungen kommen – warum sich bei X-Diensten registrieren, wenn man doch z.B. eine OpenID hat.
Auch CardSpace ist eine Sache – Produktiv hab ich das (bis auf den Blog Kim Cameron) nicht gesehen.
Jetzt eine Frage an meine werte Leserschaft: Wer von euch weiß was OAuth ist und was man damit machen kann? So richtig schlau werde ich aus der Seite nicht.
Wo stehen wir momentan?
Momentan beschäftigt mich das Grundkonzept von diesen verschiedenen Diensten etwas – da mir leider da auch TDD nicht weiterhelfen kann, versuche ich mich erstmal zu informieren.
Ein paar interessante Links (neben den MVC Storefront) :
Das wäre es (leider) für heute erst mal.
Ein Hinweis noch: Mir ist bewusst, dass ich mich doch recht lange an einem doch trivial klingenden Thema aufhalte – allerdings genau wegen solchen Sachen mach ich das ja auch. Wer würde das denn sonst auch bezahlen?
Fast jede Anwendung die heute irgendwie läuft, benötigt ein Login oder man kann bestimmte Profildaten anhäufen etc. Daher ist das Usersystem die erste große Hürde, die es zu überwinden gilt.
Solch ein Usersystem ist prinzipell recht schnell gemacht, allerdings muss das Usersystem laut den Anforderungen auch andere Provider (wie OpenID, Windows Live ID etc.) unterstützen.
Im Mittelpunkt steht der “User” – in dem Fall ein ganz normaler Nutzer unser Applikation. Ein “User” kann mehrere “Identitäten” haben, z.B. eine Windows Live ID, eine OpenID oder auf ein eigenes Login-System setzen. Ob ich das später tatsächlich einbaue ist eine andere Sache, allerdings sollte das System möglichst “offen” sein.
Dann hat natürlich unser “User” “Accountdaten” (also Profildaten etc.) die wir in unserer Applikation brauchen – die könnte man später z.B. über bestimmte Connectoren befüllen – das ist aber nur eine fixe Idee.
Diese Accountdaten werden momentan durch diese recht einfache Userklasse repräsentiert:
Das “Problem” der Zuordnung
Mein selbst festgelegtes Ziel hat natürlich ein Haken: Ein User hat mehrere Identitäten – eine eindeutigen Namen brauch ich also, um genau zu sagen, dass Nutzer A der sich gerade mit seiner Windows Live ID anmeldet auch wirklich Nutzer A ist.
Dafür ist in der User-Klasse der “AccountName” vorgesehen – ein eindeutiger Name der zu beginn vom Nutzer festgelegt wird.
Die “ID” (eine GUID) wird in dem Falle vielleicht nicht mehr benötigt, allerdings könnte ja noch die Anforderunge rein kommen, dass jemand seinen Nutzernamen ändern möchte – daher die “ID“.
Der “IdentificationName” ist der Name, mit dem der User sich gerade angemeldet hat, also wenn er z.B. seine OpenID angegeben hat, steht da “http://user.myopenid.com” da.
Ablauf der Anmeldung / Registrierung
1. User registriert sich mit einer beliebigen Identifikation (”IdentificationName”) und einem Nickname (”AccountName”)
2. User wird im System angelegt und in einer Zuordnungstabelle wird festgehalten, das User A mit der Identifikation A sich anmelden darf.
3. User meldet sich ab.
4. User meldet sich wieder mit seinem “IdentificationName” und dem dazugehörigen Passwort an (seinem OpenID-Passwort z.B.)
5. In der Zuordnungstabelle wird überprüft, ob User X sich mit der ID überhaupt anmelden darf, wenn ja, dann ist er eingeloggt.
6. Wenn er eingeloggt ist, darf er seine Accountdaten weiter pflegen.
Identification-Interface
Momentan ist das Interface noch recht “klein”:
Ein Fall fürs Prototyping
Da ich momentan doch noch recht unsicher über das Design bin, werde ich erstmal ein paar Provider “prototypen”, sodass ich sehen kann, ob es überhaupt so machbar wäre.
Fazit & Feedback
Code gibt es heute leider nicht zu sehen, zwar läuft bereits ein UnitTest erfolgreich durch, allerdings muss mal ein, zwei “richtige” Loginsysteme integrieren um eine schlüssige Aussage machen zu können.
Wie immer gilt: Feedback ist gern gesehen – wenn ihr sagt, dass ich mich hier total irre oder etwas wichtige übersehe, dann nur zu
Ich bemüh mich in dieser Woche ein Login-System auf die Beine zu stellen. Wenn dies erstmal steht schauen wir weiter
Der TFS ist mit seinen ganzen tollen Funktionen sehr vielseitig, allerdings sollte man bereits am Anfang auf eine Sache achten: Wie strukturiere ich das Projekt?
Damit sind keine “logischen” Strukturen gemeint, sondern wie lager ich die Dateien richtig im TFS? Gibt es einen Leitfaden?
Die gute Nachricht: Ja – den TFS Guide!
Hinweis: Im Rahmen des ReadYou-Projektes werde ich den Source Code bei Codeplex (welche auf den TFS einsetzt) versuchen nach diesen Best-Practices unterzubringen.
Da dies allerdings (jedenfalls bei mir) immer mal wieder Kopfzerbrechen bereitet, ein kleines HowTo:
Warum das ganze eigentlich?
Auf der Codeplex Seite des TFS Guides findet man viele Tipps, warum man dies so oder so machen sollte – ein deutlichste Bild nehm ich direkt mal aus den Guide (Seite 50):
Erklärung:
Es gibt in der Entwicklung immer einen “Main” Pfad – an diesem Pfad wird ständig gearbeitet. Irgendwann wird ein “Release 1” herausgegeben.
Jetzt beginnt die Phase, in der sicherlich im “Release 1” Bugs auftreten und Fixes etc. nachgeliefert werden müssen. Natürlich muss unser Hauptentwicklungsteam die Software während dieser Zeit im “Main” Pfad weiterentwickeln können.
Jetzt könnte es aber passieren, dass im “Release 1” ein Fehler auftritt der unbedingt gefixt werden muss – allerdings ist die Entwicklung zum “Release 2” schon sehr weit fortgeschritten. Komplette Codeteile sind neu geschrieben wurden! Ein “Patch” ist daher jetzt nicht machbar.
Das sowas nicht passiert macht man “Branches” (dt.: Zweige) und “merged” (dt.: wieder vereinen) die am Ende wieder (wenn es nötig ist) in den Entwicklungszweig.
Das mal als kurze Erklärung – das PDF gibt noch mehr Hinweise, warum und wieso man sowas machen sollte.
Schritt 1: Workspace anlegen
Als erstes muss auf unser Entwicklungsmaschine ein Workspace zum TFS Projekt her – daher gehen wir auf den Team Explorer -> Soure Control (kann hier runtergeladen werden) und klicken einfach beim Projekt auf “Get Latest Version“:
Dort wählt man einen Speicherort aus – nachdem das gemacht wurde, sollte sowas zu sehen sein:
Falls man feststellt, dass das Verzeichnis nicht das richtige war, muss man das Mapping im Workspace-Setting umstellen. Um hier rein zu kommen einfach mal hier klicken:
Schritt 2: Ordnerstruktur über den Team Explorer / Source Control anlegen
In diesem Schritt legen wir jetzt unsere Ordnerstruktur an – das wird genauso auch auf der Clientseite im Workspace übertragen.
Am Ende sollte man sowas haben – ein leeres Grundgerüst:
Schritt 3: Leere Solution anlegen
Jetzt legen wir uns eine leere Solution an, dabei muss die Location auf “[Workspace-Ordner]\Main\Source” stehen!
Nachdem das gemacht wurde, sieht man das Solution-File auch bereits im TFS in der Source Control Ansicht:
Schritt 4: Projekte anlegen
Die Projekte liegen nicht direkt mit dort, wo die Solution liegt, sondern in einem extra Source Ordner (im TFS Guide steht dazu, warum und wieso ), daher habe ich einfach zwei Solution-Folder “Source” & “Tests” (für die UnitTest-Projekte) angelegt:
Wichtig ist hierbei auch, dass als Location auch der “\Source” Unterordner angegeben ist – ansonsten wird es falsch abgespeichert:
Tipp: Falls man was auf der Clientseite falsch gemacht hat, muss es auch auf dem TFS berichtigt werden – dazu gibt es einen unscheinbaren “Delete”-Knopf. In der Source Control Sicht den entsprechenden Ordner markieren & löschen und dann auf “Checkin pending changes” – jetzt ist er wieder weg 
Schritt 5: Fertig
Wenn wir alles richtig gemacht haben, sieht es so aus:
Ich muss allerdings zugeben, dass die Solution-Folder nicht sein müssen, wichtig ist erstmal, dass es auf dem Server auch richtig hinterlegt ist:
Abschließender Hinweis:
Das ist natürlich nur so einfach bei einem neuen Projekt – alte Projekte in diese Struktur packen ist sicherlich nicht ganz so leicht, aber auf der TFS Guide Seite findet man noch sehr viele Informationen darüber.
Falls irgendwas mit meinen Ratschlägen nicht stimmt, dann einfach Feedback geben
Gestern habe ich bei Codeplex ein “ReadYou” Projekt angelegt.
Info am Rande: Die “HowTos” sind allgemeiner gehalten – in der Kategorie “HowToCode” dreht es sich um zusammengesetze spezielle Sachen, wobei ich hier “HowTos” etc. verlinke – so ist jedenfalls momentan meine Vorstellung von diesen beiden Kategorien
Um einen Ãœberblick über die verschiedenen Tätigkeiten bei “ReadYou” zu behalten muss unbedingt eine ToDo Liste her.
Info am Rande: Ich dokumentiere dies Schritt für Schritt – sodass ich dies evtl. später auch mal unseren Azubis vermachen kann, daher auch der “low-level” Einstieg
Ob das Feature auf Codeplex genau so genutzt wird, weiß ich natürlich nicht – da am Ende allerdings ein Team Foundation Server steckt und dort solche ToDos sich (mehr oder weniger komfortabel) als WorkItem wiedergeben lassen, werde ich dies hier auch machen
Codeplex: “Issue Tracker”
Mit dem Tracker kann man sehr leicht WorkItems/Issues/Features anlegen.
Man kann dazu viele Details mit hinzufügen:
Komponenten – Grobstruktur
Codeplex bietet nettes kleines Feld namens “Component”:
Hier können wir unsere Applikation erst mal grob strukturieren:
Genau diese Komponenten legen wir an:
Visual Studio 2008: Team Explorer Integration
Da ich natürlich nicht immer auf die Codeplex Seite die neuen ToDos anlegen möchte, geht dies auch mit dem Team Explorer. Hier sehen wir die selben Input-Felder wie auf der Website (diese Eingabemaske ist vom TFS Projekt Template abhängig) :
Visual Studio 2008: ToDos erstellen
Im ersten Schritt habe ich erstmal meine nächsten Schritte als WorkItem beschrieben:
Wie zu sehen ist, soll erstmal eine Ordnerstruktur her und wir widmen uns gleich zu beginn einem Kernelement: Das User System.
Was haben wir hier gelernt?
Ãœberblick über ein Projekt zu behalten ist nicht ganz einfach – ein ToDo Zettel ist ganz nett, allerdings werden wir später noch herausfinden, was bei diesen WorkItems noch schick ist und warum es sich lohnt, so eine Art Kreislauf einzuhalten:
Schritt 1: Anforderung kommt rein
Ein Kunde (in dem Fall ich) möchte ein bestimmtes Features, z.B. sollen sich User anmelden können usw. (siehe hier).
Schritt 2: Bewerten / Aufwand abschätzen
Der Schritt ist etwas “schwammig” bei mir hier – normalerweise sollte der Entwickler an dieser stelle bereits eine ungefähre Ahnung haben, was da eigentlich gewollt ist und auch eine Ahnung haben, wie lange dies oder jenes dauert. Hier kann auch eine Konzeptionsphase sein (oder sogar sollte )
Schritt 3: In entsprechende WorkItem umwandeln
Wenn das soweit ok geht (und vom Projektleiter abgesegnet wurde etc.) müssen wir die schwammigen Featurebeschreibungen in konkrete ToDos umwandeln.
Es kann auch sein, dass hier gar kein WorkItem abfällt, weil es z.B. kein Code zu schreiben gibt und auch sonst eher eine “administrative Aufgabe” ist.
Schritt 4: Implementieren
Da wir hier nach Test-Driven-Development vorgehen, wird während dieser Phase bereits ausgiebig getestet – jedenfalls wird hier alles eingebaut, was nötig ist um das zu erfüllen was gefordert ist.
Schritt 5: Testen
Hier sollte alles nochmal überprüft werden – nach dieser Phase geht es live!
Schritt 6: Ausliefern & WorkItem schließen
Wenn alles funktioniert, dass Feature fertig implementiert wurde und auch beim Kunden läuft, können wir hier das WorkItem schließen und können uns erstmal zurücklehnen
Da man mit den Unit-Tests in Zusammenhang mit WorkItems was schickes machen kann, wollte ich dies nochmal hervorheben.
Im nächsten Blogpost gibt es also das erste mal direkten Code zu sehen – jedenfalls werden wir das Visual Studio nicht nur zum Managen nehmen, sondern auch zu unserer eigentlichen Aufgabe zurückkehren: Coden!
Für das Community-Projekt “ReadYou” habe ich nun ein Codeplex Projekt angelegt. Ich werde demnächst ein größeren ReadYou Post bringen – dies ist zur Vorbereitung
Das HowTo soll nur Anlaufinformationen zu dem ohnehin einfachen Registrierprozess darstellen (falls jemand anderes auch das Interesse hegt, bei Codeplex ein Projekt anzulegen) :
Nachdem wir angemeldet sind, können wir einfach auf der rechten Seite ein neues Projekt anlegen:
Die wichtigsten Daten angeben:
Den Codeplex User Agreements noch zustimmen:
Und da ist unser Projekt:
Nächster Schritt (bzw. hat man Zeit bis zum Releasen) :
Der Wahl einer Softwarelizenz. Es gibt bei Codeplex einige Open Source Lizenzen zur Auswahl, darunter die GPL, Apache Licence oder auch die MS-PL. Welche die richtige ist, ist momentan für mich auch ein Rätsel
Frist: 30 Tage bis zum Löschen!
Wie bereits oben in dem Screenshot zu sehen ist, gibt es beim Anlegen eine Deadline von 30 Tagen – in dieser Zeit muss das Projekt gepublished werden (ist das überhaupt ein Wort? ) – keiner mag leere Projekte, daher dieser Filter.
Wie verbinde ich mich nun mit dem Projekt?
Ich werde den TFS Team Explorer nehmen, es gibt allerdings noch andere Clients.
Interessant: Continuous Integration mit CruiseControl.NET ist es mit Codeplex möglich – siehe hier. Vielleicht ist das für später ganz interessant.
Die eigentlichen Verbindungsdetails lassen sich über den Reiter “Source Control” abrufen:
Das ganze tippen wir mal in unser Visual Studio über den Team Explorer ein:
Und siehe da – unser leeres Projekt:
Jetzt können wir anfangen Work Items/Source Code hochzuladen – wie genau und was da die Best Practices sind, versuche ich in ein paar HowTos bzw. einem größeren ReadYou Post zu veranschaulichen.
Weitere Informationen findet man auf der Codeplex Seite selbst.
Da hat sich wohl der Fehlerteufel eingeschlichen – in den letzten beiden Blogposts war immer von “YouRead” die Rede, dabei heisst es eigentlich (jedenfalls ist diese Domain jetzt dafür gedacht “ReadYou“.
Spricht sich auch deutlich einfacher (und der Titel war auch bereits bei dem UI Prototyp zu sehen)
Der Fehler wurde mir bewusst, als ich voller Stolz meiner Freundin berichtet habe, dass ich nun mit “YouRead” angefangen hab.
Naja, Namen sind am Ende auch Schall und Rauch – freuen wir uns also nun auf viele “ReadYou” Blogposts
In dem letzten “ReadYou” Post ging es allgemein um den Gesamtplan – als erstes möchte ich nochmal komplett ohne Code arbeiten und auch keine großen Gedanken zur Architektur machen.
Hier geht es um die Anforderungen die ich an das System habe. Neben den bereits gestellten Qualitätsanspruchen (Source Control, Tests, Dokumentation) sollten auch gewisse Grundfunktionen enthalten sein.
Wichtiger Hinweis: Ich werde die Anforderungen bewusst “simpel” fassen – im professionellen Umfeld sollte an dieser Stelle besonders viel mit dem Kunden geredet werden um herauszufinden, was er eigentlich will!
Was genau muss die Software/Plattform leisten?
Bilder sagen manchmal mehr als tausend Worte (und vor allem empfinde ich es dann meist viel logischer, wie das hinterher aussehen muss):
Aufmerksamen Lesern des Blogs sollte dieses Bild aus dem UI Prototyping mit Powerpoint bekannt vorkommen.
Ich liste jetzt mal alle Funktionen auf:
)Um es kurz zu sagen: Typische Communityseite – wobei ich die Anforderungen hier nicht so eng fasse.
Eine interessante Sachen die ich gerne einbauen würde:
Das ASP.NET Membership-System gefällt mir nicht wirklich – es ist nett, hat aber seine Tücken und ist bei manchen Sachen (Profiles z.B.) nicht wirklich schön.
Zudem möchte ich die Authentifzierung von den eigentlichen Nutzerdatenzugriff trennen, weil ich bislang häufig bei Projekten folgendes Szenario hab:
Insbesondere durch die Anforderung, die ich mir selbst gestellt habe, als Authentifizerung auch OpenID, Windows Live etc. zu unterstützen, wären die Userdaten und die Userauthentifizierung sowieso getrennt.
“AuthenticationRepository” & “UserRepository”:
Ich bin sehr angetan von Rob Conerys Architektur mit den Pipes & Filters Modell und dem IQueryable Interface.
Als momentane Idee steht daher solch eine “Grobe”-Architektur:
Diese “Architekturgedanken” sind hier für die Erklärung der Anforderung zu verstehen. Code etc. wird es erst später geben
Data:
Hier versteh ich die verschiedenen Datenquellen – z.B. eine Oracle-DB, eine SQL-DB, Windows Live oder OpenID (wenn es um die Authentifizierung geht).
Repository;
Hier ist die Datenzugriffsschicht – als wäre hier angenommen LINQ to SQL/ADO.NET EF/NHibernate/SubSonic oder die Windows Live API etc. einzubauen.
Service:
Der Service sollte so lose wie möglich an das “Backend” gekoppelt sein – ich denke dies hier ist ein nettes Einsatzgebiet von Dependency Injection. Dieser Serivce wird im Frontent aufgerufen und gibt das an die entsprechenden Repositories weiter.
Mein Wunschtraum:
Der Idealzustand dieser Plattform wäre, wenn ich an einer Codestelle oder über Konfiguration mein “Datenquellen” angeben kann, z.B.:
Variante A)
Nimm als Authentifizierungsquelle und Userquelle den SQL Server.
Variante B)
Nimm als Authentifizierungsquelle das Active-Directory und als Userquelle die Oracle DB
Am Ende muss man “nur” einen entsprechenden Provider bereitstellen und ich will Service nichts großes ändern müssen – ob das so klappt, wage ich jetzt mal zu bezweifeln, da die Anmeldedaten auch unterschiedlich sind – aber das wird eine interessante Sache für die nächsten Blogposts
Alles klar?
Kunde: “Falls Sie noch Fragen haben, melden Sie sich einfach. Ich denke, dass ist eine machbare kleine Anwendung – das dauert bestimmt nicht lange.”
Programmierer:
Feedback:
Auch wenn ich einen möglichst “professionellen” Ansatz verfolgen möchte, will ich hier möglichst bald euch Code präsentieren. Die Rubrik heisst ja auch “HowToCode” und nicht “HowToRequirementsManagement”, daher sei mir hoffentlich die spärlichen Anforderungen verziehen
Aber wenn ihr noch Vorschläge habt (was unbedingt mit rein müsste, und was man mit bedenken sollte), dann immer her damit.
Ausblick:
Die Idee mit der Authentifizierung/Userdata-Sache werde ich sicherlich erstmal prototyisch das nächste mal in Angriff nehmen und genauer auf die anderen Architekturpunkte eingehen.
Der Posttitel klingt schon mal recht hochgegriffen und es ist für mich auch eine Art Experiment und hoffe, dass es (früher oder später) auch Feedback gibt
Was ist “ReadYou”?
Trotz des “Web 2.0″-Zeitalters mag ich immer noch Bücher – seien es Fachbücher oder andere Romane. Da ich allerdings langsam den Ãœberblick verliere und es meiner Freundin ähnlich geht, muss eine Plattform her, wo man solche “Bücherbestände” möglichst cool und einfach managen kann (und natürlich die ganzen anderen Community-Sachen die üblich sind).
ReadYou ist daher momentan mein Projektarbeitstitel – am Ende soll unter www.readyou.de eine kleine, schicke Web 2.0 Anwendung stehen.
Das Thema ist jetzt nicht unbedingt jedermanns Sache, allerdings sind meist die “Grundzüge” einer solchen Applikation immer gleich – um ReadYou mal mit markanten Web 2.0 Schlagwörtern zu beschreiben:
Ganz guten würden zudem noch Blogs in diesen Kontext reinpassen – aber das ist eine andere Geschichte
Aha… was hat das mit uns zutun?
Ich bin ein großer Fan von Rob Conerys MVC Storefront und hab bei seinen Videos einiges gelernt:
Da ich zumeist noch das Problem bei privaten Projekten hab, dass ich irgendwann die Lust verliere, mach ich es diesmal von Anfang an “offen” für jeden – damit ich es nicht irgendwann auf meiner Platte verliere. Dabei soll nicht nur der Source-Code “offen” sein, sondern auch warum ich diese und jene Entscheidung treffe oder warum ich das Tool nehmen möchte.
Es soll eine m̦glichst professionelle Applikation rauskommen, welche eine m̦glichst robuste Architektur aufweisst, gut getestet ist und auch (das leidige Thema der Entwickler) sogar dokumentiert ist Рalso ein m̦glichst professioneller Ansatz.
Da ich natürlich kein Experte in TDD, Dokumentieren, Toolauswahl, Architektur etc. bin, ist Feedback besonders wichtig
Was soll das bringen?
Am Ende soll möglichst eine Art “Leitfaden” entstehen (die Applikation ist quasi das Nebenprodukt), den Anfänger ebenfalls beschreiten können – und auch verstehen, warum diese und jene Entscheidungen getroffen wurden und auch (was sicherlich passieren wird), dass manche Entscheidungen vielleicht unklug waren.
Es sollte nicht als pure deutsche Kopie von Robs Videos zu sehen sein (ich glaub nicht, dass ich so gute Screencasts überhaupt machen könnte), sondern ein Lernexperiment für jedermann – vergleichbar mit einem größeren HowTo – diesmal “HowTo code ReadYou”
Themen/ToDo´s die ich mir vornehme:
Anforderungsmanagement ist ein wichtiger Punkt bei einem Software-Projekt. Da ich hier allerdings selber der Kunde bin, werde ich meine Anforderungen und ungefähren Designvorstellungen selber schreiben – Abschätzungen oder ähnliches werden aber nicht gemacht
Anhand dieser Anforderungen muss eine entsprechende Architektur entworfen werden – dabei werde ich mir sicherlich die eine oder andere Idee bei Rob nochmal genauer anschauen.
Als Source Control ist momentan Codeplex meine erste Wahl (TFS Infrastruktur). Hierbei muss ich mal schauen, wie weit man es da treiben kann РStichwort Continuous Integration). Builds sollten m̦glichst automatisch ablaufen k̦nnen Рdaher werde ich mich an dieser Stelle MSBuild widmen. Hier bin ich mir noch etwas unsicher was Codeplex bietet und wie ich das am cleversten anstelle Рaber an dem Punkt bin ich ja noch nicht
Ich versuche möglichst mich nach dem TDD Mantra “Test-First” zu richten – sodass eine möglichst robuste Applikation am Ende rauskommt. Auch Themen wie Dependency Injection, MSTest als Testframework, ASP.NET MVC nehm ich mir vor.
Da Source-Code möglichst dokumentiert sein sollte, soll auch hier mal von Anfang an daran gedacht werden – ich probier es mal mit Sandcastle (hier & hier gibt es einen guten “Ãœberblick” über die neusten Versionen)
Feedback
Wie bereits oben erwähnt ist Feedback natürlich sehr wichtig – wenn ich aus eurer Sicht was vergessen hab, ihr das Konzept blöde findet oder was auch immer – (konstruktive) Krtik ist immer gut
Ich hoffe ich kann in den nächsten Tagen die ersten Themen/ToDo´s angehen
Deutsch
Englisch
