Hallo Christian,

ich kann mal umrei�en wie wir es hier machen. Wir entwickeln ein
Internetportal f�r den Support in unserer Firma.

Kern des Produkts sind nat�rlich die Businessobjekte. Diese sollen
UI-Unabh�ngig dazu in der Lage sein, alle Transaktionen auf der
Datenbank durchzuf�hren. Gleichzeitig sollen sie die Prozesse m�glichst
greifbar objektorientiert darstellen.

Nehmen wir z.B. die Klasse SupportCall. 
Diese Klasse ist abgeleitet von BusinessObject, Businessobject kann
wiederum Funktionen haben, die Save/Retrieve von der Datenbank (bzw. dem
darunterliegenden Datenlayer) regelt.

Die SupportCall-Klasse wiederum hat als Properties z.B.
Caller - vom typ Individual, ein Individual geh�rt zu einer Company.

Was ich ausdr�cken will: Du schiebst keine IDs durch die Gegend, sondern
arbeitest mit Objekten.

Um einen neuen Call zu er�ffnen, kann das z.B. hei�en:
SupportCall call = new SupportCall();
call.Caller = myCustomer; // hier steckt man ein Customer-Objekt rein
(...)
call.Save();

Die ID des calls findest Du nun in call.ID

****

Wie anfangen?

Wir arbeiten hier nach den Grunds�tzen von Extreme Programming. Unter
anderem ist einer der Ans�tze test first. Bevor Du eine Funktion
einbaust, muss Dich ein Test dazu zwingen, das zu tun. Wahrscheinlich
brauchen wir mehr Zeit, um Tests zu schreiben, als f�r die eigentlichen
Funktionen, aber es lohnt sich, denn die Qualit�t der Software bleibt -
egal wie man die Architektur 'unter der Haube' umstellt - gew�hrleistet.
Andernfalls wird Dir das Testingframework schon rote Balken um die Ohren
hauen.
Man sichert sich Flexibilit�t, ohne die Funktionalit�t zu riskieren.

Ein Beispiel: Du baust eine Objektorientierte Anwendung. Irgendwann
kommen neue Anforderungen dazu und Du siehst, dass unter diesem
Gesichtspunkt die Architektur anders besser w�re. Jetzt hast Du mehrere
M�glichkeiten: 
- auf die bessere Architektur verzichten, da Du nicht 
  absehen kannst, ob noch alles funktioniert, wenn Du 
  erst umgestellt hast
- die Umstellung wagen und anschlie�end ein paar Wochen 
  im UI rumklicken um m�glichst alle Eventualit�ten abzudecken
- die Umstellung machen und die Tests laufen lassen.

Wir haben hier schon innerhalb weniger Tage sehr viel Architektur
umstellen k�nnen; die Qualit�t ist dabei gleich geblieben.
Das gleiche, wenn ein Fehler auftritt: Der Fehler wird erst gefixt, wenn
ein Test das verlangt. Man erreicht damit, dass der gleiche Fehler keine
zwei mal auftreten kann.

Unsere Werkzeuge f�r die Businessobjekte sind:
- Visual Studio.NET
- Zum Testen csUnit http://www.csUnit.org/
  Auf csUnit.org und im Programmverzeichnis (wenn installiert) sind
Beispiele.
- Zum Refaktorieren C#Refactory (http://www.xtreme-simplicity.net/)

Da es um Web-UIs zu testen noch keine brauchbare .NET-L�sung gibt,
verwenden wir an dieser Stelle Java:
- IntelliJ IDEA als IDE http://www.intellij.com
  (klappt auch super mit eclipse (kostenlos))
- JUnit f�r beide IDEs als Plugin erh�ltlich, sonst
http://www.junit.org/
- httpunit, um objektorientiert auf webseiten zugreifen zu k�nnen
(http://httpunit.sourceforge.net/)

Der komplette test first - Ansatz (und nat�rlich vieles mehr) wird auf
einschl�gigen eXtreme Programming - Websites erkl�rt:
http://www.xprogramming.com/
http://www.xpexchange.net/
http://xp.c2.com/ExtremeProgramming.html

Was ich sagen will: 
Verschwende nicht zu viel Zeit in die Architektur. 
Keiner ist so genial, dass er zu Projektbeginn alles �berblicken kann. 
Zieh Deine Anwendung testgetrieben, St�ckchen f�r St�ckchen hoch. 
Refaktoriere nach jedem St�ckchen 
(kann man den Code einfacher schreiben? Gibt es bereits im Projekt Code,
der sowas �hnliches macht? Kann man Code zusammenfassen? Wenn ja, dann
tun). 
Codeduplikate vermeiden (http://c2.com/cgi/wiki?OnceAndOnlyOnce)).
Wenn sich die M�glichkeit bietet: Verwende design patterns
(http://c2.com/cgi/wiki?DesignPatterns)

Ich w�sste noch einiges zu erz�hlen. Vielleicht mehr bei Gelegenheit.

Gru�
Markus

------------------
Professionelles .NET Hosting auf leistungsf�higen Servern.
ASP.NET, VS.NET, XML, CDO, SQL 2000 und vieles mehr.
Informieren Sie sich jetzt unter http://www.aspnet.de
_______________________________________________
Asp.net mailing list
[EMAIL PROTECTED]
http://www.glengamoi.com/mailman/listinfo/asp.net

Antwort per Email an