Ok, verstehe, eigentlich bin ich auch Fan von XP... :-) Wenn ich's richtig verstanden habe sollte ich also z.B. mit einer allgemeinen Klasse Login Anfangen, die durch �berladen dazu gebracht wird, eine Art Allgemeing�ltigkeit zu erlangen, sprich in Zukunft wiederverwendbar ist...
Und dann eine Klasse, die alle m�glichen Formen der Datenbankabfrage bereit stellt? Ok, aber jetzt denke ich wieder kurz nach,und stelle mir die Frage, kann eine solche Klasse auch in Zukunft funktionieren? Antwort eigentlich ja schon , oder ? Also mehr als Select, Insert und Update bzw Delete wird ja nicht vorkommen....? Ok, hat jemand ein Simples Beispiel ,wie ich die Klasse Datenbank so angehe, dass Sie dynamisch ist, sprich z.B. eine SELECT Abfrage mit WHERE Klausel so stelle, dass Sie beliebig viele Paramter aufnehmen kann, ohne vorher zu wissen, wie viele eigentlich gebraucht werden? Oh je, ich stelle mich vielleicht an... ;-) Gruss Christian -----Urspr�ngliche Nachricht----- Von: Markus Renschler [mailto:[EMAIL PROTECTED] Gesendet: Donnerstag, 27. M�rz 2003 13:28 An: [EMAIL PROTECTED] Betreff: RE: [Asp.net] OOP / ASP.NET allgemeine Vorgehensweise 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 ------------------ 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
