-----Message d'origine----- De : Torsten Zimmermann [mailto:zimmy@;web.de] Envoy� : samedi 9 novembre 2002 22:39 � : C Sharp Objet : [dotnetdecsharp] AW: N-Tier Design
Hallo Daniel, Ich halte die Verwendung einer Schicht "Data" f�r zwingend, allerdings ist die Frage wie und in welcher Form nicht einfach so zu beantworten, weil es nat�rlich von den ganz konkreten Rahmenbedingungen Deines Projektes abh�ngt. Jede Datenbank verf�gt �ber eine physikalische Schnittstelle (die eigentlichen Tabellen, deren Relationen, Constraints usw.) und eine logische. Die logische Schnittstelle wird �ber Stored Procedures und Views zur Verf�gung gestellt. Auf die letztere sollte nicht verzichtet werden (was leider noch h�ufig getan wird), weil man damit sehr sch�n die interne Logik der Datenschicht kapseln kann und sich auch Fragen der Sicherheit leichter l�sen lassen. Praktisch hei�t das, dass, wenn die Datenbank eine logische Schnittstelle hat, braucht man keine Extra Schicht zwischem dem Business Layer und der DB mehr einzubringen. Es sei denn, Remoting kommt ins Spiel. >>>>> Das ist nur bedingt richtig. Wenn SPs Werte (Tabellen oder Skalare) zur�ckgeben, muessen diese behandelt werden. (DataAdaport fuellt DataSet auf, Fehlerueberpruefung, Sicherheitsabfrage (siehe Berechtigungen...)... Die SPs sind eher als eine Zwischenschicht zu sehen, als eine eigenstaendige Schicht. Sinn der DataAccess-Schicht ist es, die BusinessRules-Schicht von jeglichem Datenbankzugriff zu befreien. Die BR-Schicht soll sich auschliesslich um logische Probleme kuemmern und nicht um irgentwelche Probleme, die mit dem Datenzugriff zu tun haben. (Auffuellen mit DataAccess=Datenbankzugriff/Arbeiten mit DataSet (typed oder nicht) kann, aber muss es nicht. <<<<< Wir haben bei gr��teren Projekten eigentlich immer eine 3 + 1 Architektur verwendet und sind damit auch ganz gut klar gekommen. 3 steht f�r Datenbank mit logischer Schnittstelle (SP + Views), Business Layer (COM+ Komponenten), greift direkt auf die DB zu und dem eigentlichen Client. >>>>>> Wenn Du bereits auf der BR-Schicht direkt auf die Datenbank zugreift hast Du in der Regel folgende Probleme: -> Staerkere Abhaengigkeit von dem Datenbankanbieter (Zugriff kann ueber SQl/Oracle/OLE/ODBC...erfolgen) -> Unleserlichkeit des Codes. BR-Logik wird mit DBAccess-Code durchmischt. -> Veraenderungen auf der Ebene des DataAccess-Provider bedeutet ev. erzwungene Anpassung auf der Ebene der BRs -> Optimierungen auf der Seite der BRs als auch der DBAccess koennen nicht getrennt werden. (Falls Du mit mehreren Leuten an einem rojekt arbeitest wirst Du hier sehr warscheinlich spaeter Probleme bekommen) -> Ein wesentlicher Vorteil von COM+ ist die Unterstuetzung von Transaktionen (fuer SQL auch der Verteilten~). Wenn Du COM+ auf der BR-Schicht verwendest ohne DBAccess, dann wirst Du sehr viel leichter auch z.B. von diesen Dist.Transactions profitieren koennen, da du lediglich die DBAccess auf die Datenbank anpassen musst. Ueberhaupt brauchst Du Dich um (fast) nichts kuemmern, was den Datenzugriff betrifft. <<<<<< Das +1 steht f�r eine Bibliothek mit Datentypdefinitionen, die serializiert werden k�nnen. D.h. wir definieren eine Reihe von Datentypen (Klassen, Strukturen etc.) und bringen diese in einer Bibliothek unter, die sonst keine Logik beinhaltet. Alle anderen Schichten ordnen sich dem unter und schieben diese Strukturen immer hin und her. >>>>>> Diese Vorgehensweise ist zwar die am oeftesten verwendete, aber sie hat entscheidene Nachteile: -> Schlechte Anpassungsmoeglichkeiten bei Aenderungen am DB-Design. -> Schwiegige Abbildung auf der DB-Ebene. (Das Mapping-Problem). Desswegen ist diese Vorgehensweise eher fuer kleinere Projekte geeignet. Geeigneter fuer groessere Projekte (oder langlebigere) sind die folgenden Moeglichkeiten: -> Darstellung der Data-Entities in Form von DataSets (1:Typed oder 2:Untyped) -->1:Im Falle von a)kleineren Projekten, oder falls Performance wesentlich ist) -->2:Im Falle von groesseren und langlebigeren Projekten. Diese Form ist besenders Flexibel, da die Datenstruktur nicht im Code fest verankert ist. <<<<<< Wenn es ein gr��eres Projekt ist, wird sicherlich auch die Laufzeit des Projektes gr��er sein. Insofern solltest Du Dich unbedingt dar�ber informieren, was technologisch in naher Zukunft passieren wird und was Deine Anwendungsarchitektur beinflussen k�nnte (Beispielsweise .NET Server, der neue SQL Server mit .NET usw.) Gru�, Torsten >>>>> Gruesse, Florian <<<<< -----Urspr�ngliche Nachricht----- Von: [EMAIL PROTECTED] [mailto:bounce-dotnetdecsharp-701755@;aspfriends.com] Im Auftrag von Daniel Fisher Gesendet: Samstag, 9. November 2002 22:09 An: C Sharp Betreff: [dotnetdecsharp] N-Tier Design Hallo Liste Ich sitzt gerade vor dem start eines recht grossen Projektes und mache mir gerade gedanken �ber das Design. Nachdem ich mir "Duwamish" und "PetShop" mal genauer angeguckt habe bin ich zu folgendem Entwurf gekommen. Der Client greift auf die "Facade" zu, die auf Methoden aus dem "BusinessLayer" verweist. Die Methode im "BusinessLayer" holt sich die Daten von "DataAccess", die sich den ConnectionString aus der "Configuration" holt und als "Data" (von DataSet abgeleitet) an den "BusinessLayer" zur�ckgibt. Der "BusinessLayer" l�sst nun die Daten von "BusinessRules" verarbeiten, in "ApplictaionLog" geloggt, und stellt sie �ber die "Facade" dem Client zur verf�gung. Die Frage die sich mir nun stellt ist ob ich "Data" und "DataAccess" verwenden soll oder auf "Data" verzichte? Bei "Duwamish" ist "Data" Serialisierbar um Remoting zu erm�glichen - ist es da besser das in eine eigene Klasse zu verfrachten? Was haltet ihr von dem Design? Daniel -------- WebTier --------- aspx asmx _________________________________________________ | | ------ Middle-Tier ------- Facade Facade Facade User WS Admins | | | [---BusinessLayer---] ~~~~[ApplictaionLog] (BusinessRules) /|\ | [Configuration] | \|/ | [--DataAccessLayer--] | (Data) (DataAccess)~~~~~~ _________________________________________________ | | --------DataTier---------- SQL-Server -------------------------- | [dotnetdecsharp] als [EMAIL PROTECTED] subscribed | http://www.dotnetgerman.com/archiv/dotnetdecsharp/ = Listenarchiv | Listenregeln, sowie An- und Abmeldung zu dieser Liste: | http://www.dotnetgerman.com/listen/dotnetdecsharp.asp | [dotnetdecsharp] als [EMAIL PROTECTED] subscribed | http://www.dotnetgerman.com/archiv/dotnetdecsharp/ = Listenarchiv | Listenregeln, sowie An- und Abmeldung zu dieser Liste: | http://www.dotnetgerman.com/listen/dotnetdecsharp.asp | [dotnetdecsharp] als [email protected] subscribed | http://www.dotnetgerman.com/archiv/dotnetdecsharp/ = Listenarchiv | Listenregeln, sowie An- und Abmeldung zu dieser Liste: | http://www.dotnetgerman.com/listen/dotnetdecsharp.asp
