Comments on: HowTo: 3-Tier / 3-Schichten Architektur

By: Wachen! Wachen! Developer! Developer! « Frackmente

Wachen! Wachen! Developer! Developer! « Frackmente — Sun, 06 Nov 2011 21:02:34 +0000

[...] 3 Schichten Archi tektur Gefällt mir:LikeSei der Erste, dem dieser post gefällt. [...]

By: Keep it simple! YAGNI! | Code-Inside Blog

Keep it simple! YAGNI! | Code-Inside Blog — Fri, 04 Nov 2011 20:59:20 +0000

[...] auf dem Blog ist der Artikel HowTo: 3-Tier / 3-Schichten Architektur. Allerdings hatte ich schon einige Zeit Zweifel (Ist eine 3 Schichten Architektur mit eigener DAL [...]

By: Roberto's Blog : DI / IoC Container LightCore Teil 2: Registrierung über Xml Modul

Sun, 21 Feb 2010 18:11:01 +0000

[...] Modul erklärtWas eine drei Schichten Architektur (Tier 3 layer) ist, erklärt Robert Mühsig in seinem Post.Das folgende Beispiel wird eine Solution mit mehreren Projekten beinhalten, die eine Anwendung mit [...]

By: Christian Kiefer

Christian Kiefer — Fri, 13 Nov 2009 09:36:48 +0000

Danke für Deinen Artikel und Video,

Als Einstieg in das Thema 3 Schichten-Architektur ist dies ideal!

By: Pascal

Pascal — Fri, 31 Jul 2009 10:47:17 +0000

Danke für diesen Artikel und das Video. Einfach super. Hat mich sehr weitergebracht.

By: Jan

Jan — Thu, 28 May 2009 10:38:41 +0000

Hi,
bin eben auf die Seite gestoßen. So einen Artikel mit Beispiel habe ich schon lange gesucht. Toll. Mehr bitte …;)

Viele Grüße
Jan

By: Robert Mühsig

Robert Mühsig — Fri, 01 May 2009 18:48:12 +0000

Die Filterung sollte prinzipell im Data Layer geschehen, da es dort von der Performance her am besten passt. Dazu kannst du dir das Video von Rob Conery ansehen:
http://blog.wekeroad.com/mvc-storefront/mvcstore-part-4/
(oder auch Part 5 oder 3)

So machen wir es in einem Projekt:
Die UI (bei uns ein ASP.NET MVC Controller) sammelt die "QueryParameter" und gibt diese weiter zum Service Layer, dieser ruft dann das Repository + die Filtertechnik die Rob Conery aufzeigt auf und gibt es dann entsprechend zurück.

By: sniff

sniff — Fri, 01 May 2009 12:23:38 +0000

Danke für den Artikel.

Ich habe noch eine Frage angenommen ich möchte eine Suchfunktion, also eine Art Filter. In welcher Schicht passiert das Filtern der Daten? Sql bietet diese Funktionalität ja, kann ich alle Funktionen die Sql bietet in die Daten Schicht packen oder sollte man immer alle Daten holen und die Business Schicht dünnt die Liste dann aus?
Also z.B sowas GetUserByName("H"); gibt alle User die mit H anfangen in einer Liste zurück. Ansonsten wäre in der Datenschicht ja immer nur alle User holen, User löschen User einfügen, User ändern? Es wäre ja viel effizienter garnicht erst alle User zu holen und zu mappen.Â

By: welt-held.de » Blog Archive » 3 Schichten Modell

welt-held.de » Blog Archive » 3 Schichten Modell — Mon, 23 Mar 2009 09:46:41 +0000

[...] ein C# Projekt schön nach dem 3-Schichten-Modell aufzubauen. Ich orientiere mich dazu an einem HowTo von Robert Mühsig (netter Blog [...]

By: awaiK

awaiK — Thu, 05 Mar 2009 18:31:35 +0000

Hi, mir ist aufgefallen das bei diesem Beispiel von dem Presentation Layer (ThreeTier.ConsoleApp) eine Referenz zum Data Access Layer (ThreeTier.Data) exzitiert. Das ist nach meinem Verständnis nicht richtig, da nur von der Business Schicht eine Referenz auf die Datenzugriffsschicht zeigen sollte.

By: Midiman

Midiman — Fri, 27 Feb 2009 21:14:10 +0000

vielen Dank!
Ich suche jetzt ein paar Hinweise, wie:
1.) Users aus einer Datenbank gelesen wird. Hierzu möchte ich auf einer Klasse vom EF aufsetzen (Linq2SQL-Klasse, z.B. Customers)
2.) Die Schichten erweitert werden müssen, damit Änderungen in Frontend oder BL zur Entity weitergereicht werden.

By: Mr. Unknow

Mr. Unknow — Mon, 23 Feb 2009 14:46:58 +0000

Ein wirklicher toller Artikel, überhaupt scheint das ne Spitzen-Seite hier zu sein. Vielen Dank!

By: HowToCode: Wie bildet man einen Workflow im Code am besten ab? | Code-Inside Blog

Thu, 12 Feb 2009 11:56:18 +0000

[...] Unser Szenario ist wie beim letzten Mal eine Webanwendung, welche eine 3-Schichten Architektur implementiert. Ein User soll sich anmelden können, dabei wird geprüft, ob er [...]

By: awaiK

awaiK — Sun, 08 Feb 2009 19:00:50 +0000

Hi,
danke für dieses Beispiel.
Ich beschäftige mich momentan mit Architekturfragen, wie 3-Schichten Modell usw. Leider habe ich bis jetzt keine Literatur darüber gefunden, die mir konkrete Anwendungsbeispiele liefert, nicht nur abstraktes gerede nach dem Motto: "3-Schichten Modell ist gut, weil blablabla".

Kennt jemand weitere Quellen zu diesem Thema? Würde mich über eine Antwort freuen.

By: HowToCode: ErrorCodes, Exceptions, den User informieren, wenn etwas schief läuft - wie gehts? | Code-Inside Blog

Fri, 06 Feb 2009 00:46:37 +0000

[...] ich später auch nochmal genauer beschreiben – spielt aber jetzt keine Rolle) und nutzen eine klassische 3-Schichten Architektur mitsamt ASP.NET MVC als [...]

By: Robert Mühsig

Robert Mühsig — Fri, 28 Nov 2008 09:22:59 +0000

Jede Schicht redet nur mit der drunter liegenden. Ich persönlich mag die DataSets nicht so – besser wäre es wenn die BAL irgendwelche Business Objekte weiterreicht (z.B. gibt "GetUsers()" eine List zurück)
Das DataGridView sollte man auch an solche Objektesourcen hängen können – das ist meiner Meinung nach eine bessere Variante als DataSets hin und her zu schieben.

Also:
DAL —> DataSets/oder bereits hier schon eigene Business Objekte –> BAL —> Business Objekte —> UI
Â Â

By: jogi

jogi — Fri, 28 Nov 2008 07:49:16 +0000

danke für den tollen Artikel.
ich versuche mich gerade in das 3-schichten-modell einzuarbeiten.
Dabei steh ich vor folgendem Problem:
Im UI ist ein Datagridview, das per Dataset befüllt werden soll.
Welche Schicht liefert nun das Dataset?
Kommt vom DAL schon ein Dataset an die BAL oder liefert der DAL einen DataTable und die BAL liefert ein Dataset an das UI.Oder macht man das völlig anderst ?

By: Robert Mühsig

Robert Mühsig — Sun, 16 Nov 2008 20:17:21 +0000

Ich hatte bei dem Beispiel mein "User Entry" (also das Model der Applikation) mit in den Data-Layer implementiert, was allerdings wie Thomas schon richtig sagte, nicht ganz ok ist.
Wenn man einen O/R Mapper einsetzt (und keine POCOs), dann hat das natürlich Vorteile, aber man ist an den jeweiligen O/R Mapper meistens gebunden.
Wenn man sich viel Mühe machen möchte: Die generierten Klassen des O/R Mappers nochmal über ein eigenes Mapping auf das eigens definierte Model mappen. Das macht etwas mehr arbeit, aber man kann von Linq2Sql zu ADO.NET EF oder NHibernate etc. ändern, ohne das es das Model interessiert.
Dazu empfehle ich Rob Conerys "Storefront" Videos. So mache ich es selber momentan auch in einer Applikation.

By: Savage

Savage — Sun, 16 Nov 2008 19:24:21 +0000

Danke für deine Anregung, werde das so umsetzen. Aber mit einem komme ich noch nicht klar. Die ConsoleApp kennt den Data-Layer (zumindest das User Entity) und das sollte nach meinem Verständnis nach nicht sein, oder täusche ich mich da?
Der Vorschlag von Thomas einen "vertikalen" Layer mit Entities einzuziehen klingt ja gut, aber wie er selbst schon schreibt, kommt es zu Problemen, wenn man später einen OR-Mapper einsetzen will. Wie könnte man die "Daten-Objekte" besser verwalten?
Mein Problem ist, dass ich eine größere Web-App schreiben will und von Anfang an gleich eine saubere Architektur haben will und ich mich einfach nicht entscheiden kann.

By: Robert Mühsig

Robert Mühsig — Sat, 08 Nov 2008 13:36:22 +0000

Das Membership-System so wie es ist, passt nicht ganz in die 3-Schichten Architektur rein. Man hat z.B. Probleme in dem Business Layer auf Userdaten zuzugreifen oder Profilinformationen abzugreifen wenn man das Profilsystem von ASP.NET nutzt.
Ich hatte vor einer ganzen Weile dazu mal meine Gedanken gebloggt: http://code-inside.de/blog/2008/06/23/howto-membership-in-klassenbibliotheken-dlls/
Wichtig ist hierbei allerdings der Hinweis in den Kommentaren.
Ich würde so vorgehen (weil ich das Membership System nicht wirklich mag und das mir nur Probleme gemacht hat ) : Bau ein UserRepository / UserService also ein komplett eigenes Usersystem (ich werde in Zukunft auch mein System mal zur Verfügung stellen).
Dieses Usersystem kannst du in einer Webapplikation oder Desktopapplikation einbinden wie du lustig bist. In einer Webapplikation würde ich allerdings einen eigenen Membership Provider schreiben, damit man die Standardcontrols und eingebauten Funktionalitäten trotzdem noch nutzen kann. Dieser eigene Membership Provider ist nur ein Adapter zwischen ASP.NET und deinem Usersystem.
So ist man später sehr flexibel und kann trotzdem im ASP.NET Umfeld das gewohnte verwenden.

By: Savage

Savage — Fri, 07 Nov 2008 14:06:52 +0000

Danke für dein Beispiel. - Angenommen man würde die Consolenapplikation mit einer Websiteapplikation austauschen. In welchem Layer würdest du das Sessionhandling/Membership etc. platzieren? Die gängigen Methoden wie Forms-Authentification wären dann nämlich im Presentationlayer? Würde ich bei einer Useraktion (klick auf Button) abfragen wollen, ob sich ein User z.B. in einer bestimmten Role befindet, dann würde das auch in der Web-Applikation passieren, das sollte jedoch im Businesslayer sein, oder?

By: Robert Mühsig

Robert Mühsig — Thu, 23 Oct 2008 08:40:47 +0000

Ein direktes Buch kann ich dir dazu nicht empfehlen, aber für die Zeitsache: Schau dir mal mein YouTube Video dazu an – kaum 10 Minuten. Wichtig bei einer 3 Schichten Architektur ist einfach nur dass man sich klar macht, was welche Schicht macht.
Wenn man das beherzigt, sollte man es einfach mal ausprobieren

By: HaPe77

HaPe77 — Thu, 23 Oct 2008 07:39:50 +0000

Interessanter Artikel. Danke. Frage an die Profis hier:

Welches Buch könnt ihr einem wir mir empfehlen, der zwar schon ein ca. 2 Jahre mit .Net programmiert, aber eben sich noch immer nicht an das 3-Schichten-Model gewagt hat, weil alles immer schnell gehen muss.

Wo wird das gut und halbwegs einfach bzw. für Einsteiger verständlich erklärt?

By: Code-Inside Casts: Jetzt auch noch Videos… | Code-Inside Blog

Code-Inside Casts: Jetzt auch noch Videos… | Code-Inside Blog — Fri, 17 Oct 2008 22:38:20 +0000

[...] – wesentlich besser als Seitenweise Text. Daher habe ich jetzt mal ein Screencast zum Thema “3 Schichten Architektur” [...]

By: ntz

ntz — Sun, 21 Sep 2008 15:33:40 +0000

Die Aufteilung in verschiedene Schichten ist ein guter Anfang. Was das Logging angeht ist das ein altes Problem.
Man nennt Logging/Security/Caching etc., ja nicht umsonst cross cutting concerns.
Jahrelang hab ich mich darüber geärgert, dass aufrufe die eigenltich nichts mit der funktionalität der jeweiligen Methode zu tun hatten, den code unnötig verkomplizierten.
Klar AOP ist ein schönes Konzept, aber mit OO programmieren eben nicht einfach so umsetzbar. und die vorhanden franeworks waren bisher leider einfach viel zu umständlich.
Zum Glück habe bin ich vor einem Jahr auf PostSharp aufmerksam geworden.
Am Anfang war ich skeptisch ob es sich auch in größeren projekten nutzten lässt, aber dieser Zweifel wurde durch den Einsatz in einem ebensolchen ausgeräumt.
Dabei haben wir in allen großen Cross Cutting Bereichen auf konsequent auf PostSharp gesetzt.
Security/Caching/Logging ist auf allen layern über PostSharp Attribute implementiert worden.
zu meiner Freude sind kaum mehr stellen im code zu finden, die nichts mit der eigenltichen aufgabe der jeweiligen methode zu tun haben.

Allen die ähnliche Probleme haben, würde ich PostSharp empfehlen.
Speziell, PostSharp.Laos, da es wahrscheinlich die bedürnisse der meißten abdecken wird.

By: HowTo: Fluent Interfaces - schöne APIs mit C# 3.0 | Code-Inside Blog

HowTo: Fluent Interfaces - schöne APIs mit C# 3.0 | Code-Inside Blog — Tue, 05 Aug 2008 18:50:55 +0000

[...] Aufbau ist ähnlich empfunden wie bei diesem Blogpost – allerdings etwas vereinfacht (und sollte so nicht verwendet werden (Schnittstellen [...]

By: Robert Mühsig

Robert Mühsig — Mon, 14 Jul 2008 08:04:53 +0000

Zum Logging: Das ist eine gute Frage. Logging sollte in jeder Schicht erfolgen bzw. habe ich noch keine andere gute Methode gefunden. Dort wo geloggt werden soll, muss auch der entsprechende Loggingbefehl aufgerufen werden. Allerdings kann man über Log4Net das recht hübsch machen

Zur losen Kopplung und den Schnittstellen: Das könnte man sicherlich machen. In der "Service Factory" wird solch eine Trennung durch die Assemblys allerdings auch gemacht.
Vom Aufbau her, ist dies sicherlich ein guter Gedanke

By: Joseph Fischer

Joseph Fischer — Mon, 14 Jul 2008 07:45:51 +0000

Super Beispiel!

Ist möglicherweise der bewussten Einfacheit des Beispiels geschuldet, aber müssten die Schnittstellen zu den jeweiligen Services zur Umsetzung der losen Kopplung nicht jeweils in einerÂ getrennten Assembly angeboten werden?

By: Rob Revona

Rob Revona — Sat, 12 Jul 2008 11:20:53 +0000

Danke für das Beispiel.
Wo und wie wird denn das Logging implementiert, d.h. in welcher Schicht ?

By: Thomas

Thomas — Thu, 10 Jul 2008 18:42:52 +0000

Ich packe grundsätzlich alle Geschäftsobjekte in einen eigenen, sozusagen vertikalen, Layer:

Blabla.BL – Geschäftslogik
Blabla.DA – Datenzugriff
Blabla.BO – Geschäftsobjekte
Blabla.UI – Web-Anwendunge oder sonstwas

Ich nutze immer BO für Business Object, die Begrifflichkeit ist eigentlich wurscht – man kann’s auch Entity, Data Value Object oder was auch immer nennen – ich habe zumindest noch keine schlüssige No-Go-Erklärung für eine der Bezeichnungen gefunden.

Letztendlich kann ich die Objekte so auch in allen Schichten nutzen, z.B. auch zum Binden von Daten an einen Repeater in ASP.NET – der die Daten aus dem BL erhält, welches den DAL anzapft. Damit kann in allen Schichten mit einheitlichen Objekten gearbeitet werden, ohne mit DataSets oder sonstwas rummachen zu müssen und vor allem ohne sich zu krämen, dass man im UI jetzt etwas ausm DAL nutzt …

Funktioniert natürlich auch nur solange sinnvoll, wiem an keinen OR-Mapper einsetzt … die perfekte Lösung habe ich jedenfalls auch noch nicht.

Dein Code liefert unterm Strich trotzdem ganz gute Ansätze, deine Azubis können sich glücklich schätzen .