Einzelnen Beitrag anzeigen

Benutzerbild von Phoenix
Phoenix
(Moderator)

Registriert seit: 25. Jun 2002
Ort: Hausach
7.613 Beiträge
 
#6

Re: Client-Server Architektur oder anderes ?

  Alt 31. Okt 2009, 08:12
Ich bin gerade dabei einen (kleinen!) Bugtracker zu entwickeln, und zwar als 3-Tier Lösung.

Das Projekt brauche ich noch für mein Studium

Das Backend wie gehabt eine stinknormale Datenbank (dabei soll es wirklich vollkommen egal sein, ob MS SQL, Oracle, MySQL oder was anderes), das Middle-Tier sollen ASP.NET Web services sein (die dann sowohl SOAP als auch REST-Like angesprochen werden können). Vorne ist vorerst 'nur' eine Silverlight-Anwendung geplant, möglicherweise aber auch eine kleiner Windows-Forms Applikation zur Verwaltung (User management etc., je nachdem, ob das bei Winforms oder Silverlight schneller implementiert ist - das wird sich zeigen).

Damit ich mich nicht um den Datenbankzugriff kümmern muss, will ich einen OR-Mapper einsetzen, und habe mich in einer 20-Seitigen Analyse (das Projekt hab ich noch für mein Studium gebraucht ) für NHibernate entschieden. Zum einen weil es kostenlos ist, und zum anderen weil man damit wohl wirklich alles sauber und Testbar abdecken kann.

Das ist der nächste Punkt - ich will das Projekt wirklich sauber durchziehen. Das heisst Unit-Tests für jede Klasse mit einem Verhalten (dumme Klassen die nur Daten/Properties haben und keine Methoden braucht man nicht testen), Integrationstests für jede Funktionalität.

Das klingt alles sehr gut, sehr professionell und vor allem sehr sauber. Ich weiss aber schon gar nicht, wie ich anfangen soll und wollte gestern beginnen. Ich habe es dran gegeben und einen halben Tag nur nach Infos im Netz gesucht, wie man am besten die Daten zwischen Mittelschicht und Client austauscht (DataTransferObjects), war mir dann aber auf einmal nicht mehr sicher, wie ich meine Businesslogik von NHibernate entkoppele. Performance wegen lazy loading waren da meine Bedenken, und die Business-Objekte wären sonst auch extrem eng gekoppelt.

Kurzum: Ich habe mir erstmal zwei Bücher bestellt, von denen ich mir erhoffe dass sie meine Fragen beantworten.
Ich weiss, dass ich den Bugtracker mit Delphi in knapp einer Woche hinrotzen könnte, aber die Lösung wäre dann auf Windows begrenzt, nicht drei- sondern Zwischichtig und hätte mit Sicherheit ziemlich genau 0 Unit-tests. Ich schätze ich brauche 5-6 Wochen, wenn ich das 'professionell' machen will (ginge genauso mit Delphi, nur läuft die Mittelschicht dann leider nicht auf Linux- bzw. Mac-Servern, und das sollte schon drin sein).

Mit 3-Tier (inbesondere wenn Du auch in der Mittelschicht eine saubere Architektur haben willst) bürdest Du Dir ungeheuer viel Arbeit, Recherchen und Frustration auf - und das, bevor Du auch nur eine einzige Zeile geschrieben hast. Ich bin mir zwar ungeheuer sicher, dass sich das hinterher auszahlt.

Durch Test-Driven-Development hast Du eine bessere Trennung und bist vor allem gezwungen, alles was Du codierst zu testen, und der Aufwand - auch wenn er nur ein klein wenig höher ist - sorgt dafür, dass Du beim Entwickeln kein Feature-Creeping betreibst (also mehr als gefordert einbaust), und es zeigt Dir durch die fehlschlagenden Tests sofort auf, wenn Du später durch eine Änderung irgend was wichtiges kaputt gemacht hast. Das sorgt für weniger Fehler und damit zu einem viel geringeren Wartunsgaufwand (und zusätzlich dem Vorteil, dass eine Fehlerbehebung weniger neue Fehler produziert).

Möglicherweise werde ich den Bugtracker mal als Produkt rausbringen, deswegen will ich diesen Aufwand treiben (ausserdem muss ich darüber eine 40-Seitige Dokumentation bei meiner Hochschule abgeben, das geht mit einem 1-Wochen Delphi Projekt nicht ), aber wenn das Vorhaben kommerziell ist, dann würde ich mir ganz ehrlich folgendes Überlegen:
  • 3-tier ohne Tests ist kommerzieller Selbstmord (durch zu viele mögliche Fehlerquellen)
  • 3-tier stellt hohe Anforderungen an die Kunst des Schnittstellen-Designs
  • die Komplexität einer Anwendung erhöht sich massiv
  • Den Vorteil sieht man erst viel später

Ich würde den Ansatz also nur wählen, wenn er wirklich erforderlich ist, und dann vor allem auch konsequent Umsetzen. Die Gefahr ist groß, dass Du mit einer Security-Überprüfung nur einen Button auf der Oberfläche ausblendest, diese Überprüfung aber in der Mittelschicht vergisst (kann ja eh keiner Auslösen...). Doch, denn eine REST Schnittstelle kann jeder zur Not mit einem Browser bedienen.

Ich will Dich um himmels willen nicht davon abhalten - aber es wird ziemlich Aufwändig werden.
Sebastian Gingter
Phoenix - 不死鳥, Microsoft MVP, Rettungshundeführer
Über mich: Sebastian Gingter @ Thinktecture Mein Blog: https://gingter.org
  Mit Zitat antworten Zitat