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:
- User-Bereich:
- Login/Logout/Register/Password-Recovery
- Admin hat Management-Oberfläche
- User kann Profildaten speichern
- User sollte sich auch mit Open ID, Windows Live ID etc. anmelden können
- User kann andere User suchen etc.
- User kann Bücher anlegen (später evtl. auch Blogs)
- "Meine Seite" ähnlich wie StudiVZ Home
- Community - "Gruppen" etc.
- Bücher-Bereich:
- Anlegen / Löschen / Managen
- Bewerten
- Taggen
- Kategorisierung der Bücher
- Amazon-Anbindung
- Rezessionen verfassen (oder man nimmt die Amazon-Rezessionen über die API ;) )
- Allgemeines:
- Aktive User ähnlich wie in den ASP/MSDN Foren
- Neuste Bücher wie bei YouTube "Videos right watched now..."
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:
- Providermodell für Authentifizierung & Userdaten
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:
- Oracle-DBs mit wilden Benutzerdaten
- AD / LDAP als Authentifizierung, allerdings stammen die wirklichen Userdaten dann aus einer anderen DB
- Profildaten etc. werden extra gespeichert
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.
