Ich Finde das Thema aber sehr interessant (und sonst fast vernachl�ssigt) also wer noch seinen Senf dabeigeben will ...
-----Urspr�ngliche Nachricht----- Von: Daniel Fisher [mailto:liste@;lennybacon.com] Gesendet: Sonntag, 10. November 2002 02:02 An: C Sharp Betreff: [dotnetdecsharp] AW: N-Tier Design Hi Torsten (und Liste) Erstmal ein "Dankesch�n". Ein zweites Paar Augen haben mir sehr gut getan (ich war echt ziemlich hin und her gerissen - wenn man allein die unterschiedlichen Modelle der BeispielApps bie M$ sieht). Das mit 3+1 klingt logisch und ist ja fast wie ich mir das gedacht habe (auf jeden Fall will ich mir eine Option f�r Remoting offen halten). Ich finde die Idee mit verschidenen "Facade"�s f�r die verschiedenen Benutzergruppen (bzw. Normale User, WebServices und die Administration) sehr gut und denke, dass ich diese als Wrapper, auf die Methoden etc. die die jeweilige Gruppe ben�tigt bzw. f�r die sie authorisiert sind, zwischen Client und BusinessLayer legen werde. Gru� zur�ck, Daniel -----Urspr�ngliche Nachricht----- Von: [EMAIL PROTECTED] [mailto:zimmy@;web.de] Gesendet: Samstag, 9. November 2002 22:39 An: C Sharp Betreff: [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. 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. 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. 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 -----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 | [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
