none
Verständnisproblem Projektreferenzen zwischen3 Schichten UI-BO-BLL-DAL

    Allgemeine Diskussion

  • Guten Tag zusammen,

    ich steh auf dem Schlauch. Ich bin dabei eine Webanwendung für unsere Personalabteilung zu schreiben. Grundsätzlich funktioniert sie schon, habe aber ein Problem. Ich möchte dabei auf die 3 Tier Architecture setzen. 

    UI = Webanwendung

    BusinessObjects (BO) = eigenes Projekt Klassenbibliothek

    BusinessLogicLayer (BLL) = eigenes Projekt Klassenbibliothek

    DataAccessLAyer (DAL) = eigenes Projekt Klassenbibliothek

    Ich habe das Problem, dass ich durch die Referenzen auf die Projekte, direkt aus meinem Code in der UI Zugriff auf die DAL habe, was doch eigentlich nicht sein darf, oder?

    Alle Projekte haben einen Verweis auf die BO's.

    • BLL verweist also auf BO und auf die DAL
    • die DAL verweist auf die BO
    • und die UI verweist auf BO und auf BLL.

    Wenn ich nun das ganze erstelle, dann landen im BIN Verzeichnis der Webanwendung auch die DLL Dateien der DAL. Und die kann ich dann im CodeBehind ansprechen. Kann also von dort direkt mit der DAL "sprechen", obwohl ich nur auf BO und BLL direkt zugreifen möchte. Was mache ich verkehrt? Danke für Tipps! 

    Viele Grüße

    Daniel

    Mittwoch, 31. Januar 2018 07:39

Alle Antworten

  • Hi Daniel,
    zugreifen von der UI auf die DAL kannst Du nur, wenn Du auch Verweise setzt. Und das ist bei einer 3-schichtigen Anwendung nicht üblich. Also, ohne Verweise kann man nicht zugreifen, da der Compiler die Zugriffe nicht auflösen kann. Die DAL-dll werden aber im bin-Verzeichnis benötigt, da die BLL die Typen der DAL benötigt. Es ist also völlig normal, wenn sich alle dll im bin-Verzeichnis der Anwendung befinden (solange sie nicht im GAC registriert sind, was in einer Web-Anwendung nicht üblich uns auch nicht erforderlich ist).

    Wenn Deine Schilderung richtig und vollständig ist, dann ist das so - wie dargestellt - ok.


    --
    Viele Grüsse
    Peter Fleischer (ehem. MVP)
    Meine Homepage mit Tipps und Tricks

    Mittwoch, 31. Januar 2018 08:12
  • Hallo Daniel Tutsch

    Alle Projekte haben einen Verweis auf die BO's.

    Warum ist das so? Es sollte doch eigentlich nur eine Schicht mit der jeweils anderen kommunizieren, dies auch nur aus einer Richtung. Daher verstehe ich das folgende Verweise hin und her überhaupt nicht.

    • BLL verweist also auf BO und auf die DAL
    • die DAL verweist auf die BO
    • und die UI verweist auf BO und auf BLL.

    Das müsste doch eigentlich eher so aussehen:

    • UI -> BO
    • BO -> BLL
    • BLL -> DAL


    - Gruß Florian

    Mittwoch, 31. Januar 2018 08:37
  • Hallo Florian,

    die Business Objects dürften hier lediglich die Datenklassen, ... sein, eben in ein eigenes Projekt ausgelagert.

    Daher müssen die Projekte, die die mit diesen Klassen arbeiten wollen (und das sind nun mal alle drei anderen Projekte) auch einen entsprechenden Verweis auf das BO Projekt haben.


    Gruß, Stefan
    Microsoft MVP - Visual Developer ASP/ASP.NET
    http://www.asp-solutions.de/ - Consulting, Development
    http://www.aspnetzone.de/ - ASP.NET Zone, die ASP.NET Community

    Mittwoch, 31. Januar 2018 08:47
    Moderator
  • die Business Objects dürften hier lediglich die Datenklassen, ...


    Verstehe...

    - Gruß Florian

    Mittwoch, 31. Januar 2018 08:57
  • Hi Florian,
    in einer 3-Schicht-Archtektur gibt es die folgenden Beziehungen:

    BLL holt und übergibt an die DAL Datenobjekte, deren Deklaration in einem separaten Objekt enthalten sind, auf welches sowohl BLL als auch DAL verweisen müssen;

    UI holt und übergibt an die BLL Business-Objekte, deren Deklaration in einem separaten Objekt enthalten sind, auf welches sowohl BLL als auch DAL verweisen müssen;

    Die BLL mappt dann die Inhalte zwischen Datenobjekten und Business-Objekten. Der Einfachheit halber können die Datenobjekte von der DAL zur UI weitergeleitet und auch wieder zurückgeschickt werden. Die BLL kann bei dieser Übertragung die Inhalte der Datenobjekte manipulieren (ergänzen, verändern). Bei dieser einfachen Lösung müssen natürlich alle 3 Schichten die dll mit den Daten- bzw. Business-Deklarationen referenzieren.


    --
    Viele Grüsse
    Peter Fleischer (ehem. MVP)
    Meine Homepage mit Tipps und Tricks

    Mittwoch, 31. Januar 2018 09:01
  • Hi Daniel,
    zugreifen von der UI auf die DAL kannst Du nur, wenn Du auch Verweise setzt. 


    Hallo Peter,

    vielen Dank für deine Antwort. :-) Ich muss hier aber nochmal nachhaken
    Ich versuche mich nochmal anders auszudrücken.

    Die Verweise setze ich wie oben beschrieben, denn

    • alle brauchen Zugriff auf die BO
    • die UI brauchts zusätzlich Zugriff auf die BLL
    • die BLL braucht den Zugriff auf die DAL

    Es sei denn, ich habe hier schon aus deiner Sicht einen Denkfehler und das ganze entspricht keiner echten 3 schichtigen Anwendung?

    Setze ich diese Verweise nicht, kann ich ja z.B. nicht von der BL meine GetData Methode aus der DAL ansprechen.

    In dem Moment, wo ich in dem BLL Projekt den Verweis auf das DAL Projekt setze, und anschließend STRG+UMSCHALT+B drücke (also Projektmappe erstellen) DANN ist auch der Verweis in der Webanwendung (automatisch) auf die DAL gesetzt und ich kann logischerweise von den Webforms die DAL Methoden ansprechen (was ich eigentlich nicht will).
    Ich kann den Verweis in der Webanwendung entfernen, beim Start des Debuggens oder beim Erstellen der Projektmappe, wird der Verweis in der Webanwendung wieder automatisch ergänzt. Wenn ich den Projektverweis zwischen BLL und DAL auflöse, dann sind die Verweise in meiner Webanwendung auch korrekt. Allerdings funktioniert dann die ganze Sache nicht mehr, da die DAL Methoden aus der BLL nicht mehr zugreifbar sind.

    Über einen erneuten Klärungsversuch wäre ich dankbar.

    Viele Grüße aus dem Weserbergland

    Daniel

    Mittwoch, 31. Januar 2018 09:06
  • Hi Florian,
    in einer 3-Schicht-Archtektur gibt es die folgenden Beziehungen:


    Danke, mir ist das Modell bekannt. Datenklassen sind unsauber und lassen sich regelmäßig vermeiden, siehe dazu auch: https://blog.codinghorror.com/code-smells/


    - Gruß Florian

    Mittwoch, 31. Januar 2018 09:06
  • Hi Florian,
    ok, dann gilt der Beitrag mehr dem OP.

    Wenn Datenklassen unsauber sind, dann negierst Du auch das EF? Oder das klassische ADO.NET mit dem typisierten DataSet?


    --
    Viele Grüsse
    Peter Fleischer (ehem. MVP)
    Meine Homepage mit Tipps und Tricks

    Mittwoch, 31. Januar 2018 10:08
  • Hallo Peter,

    ich negiere gar nichts - beides sind auch keine Datenklassen.

    Ein sauberes drei Schichten Modell benötigt keine Datenklassen, dies lässt sich normalerweise Problemlos einhalten. Das ist auch nicht nur in der reinen Theorie so, sondern auch in der Praxis. In der OOP Literaratur, insb. solche die sich mit Patterns, Anti-Patterns, Design und Architektur beschäftigt erwähnt dies auch öfters. Ich kann nachvollziehen das es einem schwer fällt sich darauf einzulassen, der Gedanke "ich brauche an Stelle X, die Daten Y, also mache ich mir eine Klasse Y" hat sich mir auch schon aufgedrängt - dafür gehe ich dann aber gerade die entsprechenden Design Phasen durch, danach ist davon nämlich nichts mehr übrig und die Daten Y kommen auf einem ganz natürlichen Weg, der sich aus der Architektur ergibt, nach X.

    Die Vorteile die sich daraus ergeben sind am hier diskutierten Beispiel direkt ersichtlich, ich habe nicht drei Schichten die von einer Datenklasse abhängen. Der Zweck eines Business Layer ist auch typischerweise nicht das durchreichen von unverarbeiteten Daten aus dem Data Layer an die UI.


    - Gruß Florian


    Mittwoch, 31. Januar 2018 10:29
  • Hi Florian,
    wenn Du ohne separate dll für die Datentypen arbeitest, wo befinden sich dieses Datendeklarationen dann?

    --
    Viele Grüsse
    Peter Fleischer (ehem. MVP)
    Meine Homepage mit Tipps und Tricks

    Mittwoch, 31. Januar 2018 11:31
  • Wie Daten von einem Layer zum anderen kommen, ist in den Schnittstellen zwischen diesen Layern definiert. Das Daten Layer stellt dem Business Layer eine Schnittstelle zur Verfügung, welche die Business Logik nutzt um sein Objekt mit den benötigten Daten, durch das Daten Layer, zu befüllen - es ist für die Business Layer transparent. Gleiches gilt zwischen UI Layer und Business Layer. Die Klassen der UI wissen nichts über die verwendeten Objekte des Business Layer und das Business Layer weiß nichts über die verwendeten Objekte des Daten Layer. Es werden keine Objekte durch alle Schichten gereicht. Jedes Layer ist damit auch austauschbar und unabhängig von den anderen Layern.
    Datendeklarationen, welche irgendwelche Datenklassen beschreiben, kommen gar nicht vor.

    - Gruß Florian

    Mittwoch, 31. Januar 2018 12:05
  • Hi Florian,
    es bleibt trotzdem die Frage: wenn Du ohne separate dll für die Datentypen, die in den Interfaces beschrieben sind, arbeitest, wo befinden sich dieses Deklarationen dann?

    --
    Viele Grüsse
    Peter Fleischer (ehem. MVP)
    Meine Homepage mit Tipps und Tricks

    Mittwoch, 31. Januar 2018 12:28
  • Das klingt alles sehr interessant, aber leider kapier ich es nicht. Insbesondere bei Interfaces und diesen abstrakten Sachen tu' ich mich schwer.

    Das ist der Stein den man als One-Man-IT-Admin zu tragen hat, der von Active Directory, Android und iOS über HTML/CSS/JS, für die Website, Office, Netzwerk VLAN/WLAN/RADIUS Gastnetz, VPN und Firewall, IP-Telefonie und TK Anlage, Windows Server, SQL + Webanwendungen und Datenschutz on top alles abdecken soll. Da bleibt halt was auf der Strecke.

    Entschuldigt bitte das rum-gejammere... geht wahrscheinlich vielen so.

    Mittwoch, 31. Januar 2018 12:33
  • Hallo Florian,

    irgendwo müssen die Entitäten abgebildet werden. Ich weiß ehrlich gesagt nicht, wie Du darauf kommst, dass nirgendwo irgendwelche Objektstrukturen der Daten bekannt sein sollen.

    Natürlich muss die UI wissen, was genau da kommt und wie es aussieht. Wo das definiert ist, sei dahingestellt aber was soll uns

    Die Klassen der UI wissen nichts über die verwendeten Objekte des Business Layer und das Business Layer weiß nichts über die verwendeten Objekte des Daten Layer

    sagen?

    Definierst Du für jede Schicht eigene Klassen und transformierst die für jeden Zugriff hin und her?


    Gruß, Stefan
    Microsoft MVP - Visual Developer ASP/ASP.NET
    http://www.asp-solutions.de/ - Consulting, Development
    http://www.aspnetzone.de/ - ASP.NET Zone, die ASP.NET Community

    Mittwoch, 31. Januar 2018 12:52
    Moderator
  • Hallo Peter.

    Es befindet sich alles in seiner jeweiligen Schicht, denn da gehört es hin. Es ergibt sich kein Bedarf für irgendwelche Extra Deklarationen.


    - Gruß Florian

    Mittwoch, 31. Januar 2018 13:19
  • Hallo Stefan,

    ich rede von Transparenz. Dem Grund für das 3 Schichten Modell.

    Jede Schicht hat eine bestimmte Aufgabe, es geht etwas rein und es kommt etwas raus, selbstverständlich werden Daten transformiert, wenn dem nicht so wäre kann ich die Schicht auch weg lassen, den sie tut ja nix. Natürlich hat jede Schicht eigene Klassen, mit eigenen Aufgaben. Wie diese Klassen aussehen müssen kann nur der jeweiligen Schicht bekannt sein, denn nur diese weiß was sie damit macht.


    - Gruß Florian

    Mittwoch, 31. Januar 2018 13:28
  • Hallo Florian,

    also würde es in deinem Fall in der UI, im BL und im DL jeweils eigene Klassen geben, die dann bspw. beim Abruf aus der Datenbank dreimal transformiert werden?

    Aus Datenbank lesen

     -> im DL über DataReader oder DataTable in Datenklassen
       -> DL Klassen in BL Klassen
         -> BL Klassen in UI Klassen

    ? So richtig?

    Falls ja, wo finden bei dir dann die jeweiligen Transformationen statt? Gibt es dafür eigene Schichten, die nur für die Transformationen vorhanden sind? Oder ganz anders?


    Gruß, Stefan
    Microsoft MVP - Visual Developer ASP/ASP.NET
    http://www.asp-solutions.de/ - Consulting, Development
    http://www.aspnetzone.de/ - ASP.NET Zone, die ASP.NET Community

    Mittwoch, 31. Januar 2018 13:46
    Moderator
  • Hallo Stefan.

    Dein Anwendungsfall ist ziemlich langweilig, und spricht im Grunde das an was ich vorab schon erwähnte, wenn die BL nichts zu tun hat, dann kann sie auch wegfallen.

    Typischerweise ist Datenbank lesen eine Aufgabe der DL, diese Schicht holt die Daten (hier wohl aus Datenbank, allgemeiner aus einer Datenquelle) und stellt sie über die Schnittstelle der BL zur Verfügung (das wäre dann wohl dein "Transformation" genannter Vorgang) - die BL wird dann irgendetwas mit den Daten machen (in deinem Anwendungsfall, nichts), das Ergebnis über die Schnittstelle zur UI weiterreichen, welche es für den Benutzer visualisiert.

    Das ganze gibt es auch als Bildchen, inkl. Varianten die nicht strikt getrennt sind: https://glossar.hs-augsburg.de/Schichtenarchitektur


    - Gruß Florian

    Mittwoch, 31. Januar 2018 14:17
  • Hi Florian,
    ich verstehe unter einer Schicht letztendlich konkrete dll's. Damit z.B. die BLL und die DAL die gleiche Schnittstellenbeschreibung nutzen, müssen sie beide die gleiche dll referenzieren, die die Schnittstellenbeschreibung enthält. Man kann sich darüber streiten, ob die Beschreibung der Datenobjekte (resp. Interfaces) der DAL oder der BLL zuordnet werden. Für mich sind sie immer relativ losgelöst von beiden bzw. dazwischen liegend und deshalb konzentriere ich sie in einer separaten dll, die sowohl BLL als auch DAL referenzieren.

    Im vereinfachten Fall, wenn die BLL nichts großartig mappen muss, kann ich dann auch diese dll in der UI nutzen, was die eigentliche Ausgangsfrage war.


    --
    Viele Grüsse
    Peter Fleischer (ehem. MVP)
    Meine Homepage mit Tipps und Tricks

    Mittwoch, 31. Januar 2018 14:34
  • Hallo Peter, Völlig richtig. Die Schnittstellenbeschreibung von den Schichten zu trennen ist auch gängige Praxis.

    - Gruß Florian

    Mittwoch, 31. Januar 2018 14:48
  • Hallo Florian,

    ich vermisse in deinen Antworten immer noch die Angaben, wo genau die Transformation (also die Umwandlung  eines Datenobjekts in ein Businessobjekt und anschließend von einem Businessobjekt in ein UI Objekt in den von dir genannten Schnittstellen) stattfindet und vor allem, woher diese Schnittstelle weiß, wie sie bspw. ein Datenobjekt in ein Businessobjekt wandeln muss.

    Evtl. liegt es ja auch nur an den Begrifflichkeiten aber es würde mich schon interessieren, wie Du dir das vorstellst, wenn überhaupt keine der Schichten auch nur irgendeine Ahnung von den Klassen der anderen Schicht hat.


    Gruß, Stefan
    Microsoft MVP - Visual Developer ASP/ASP.NET
    http://www.asp-solutions.de/ - Consulting, Development
    http://www.aspnetzone.de/ - ASP.NET Zone, die ASP.NET Community

    Mittwoch, 31. Januar 2018 16:01
    Moderator
  • Hallo Stefan,

    ich weiß nicht woher deine Vorstellung von irgendwelchen Transformationen kommt. Du scheinst die Vorstellung zu haben das diese Schichten den Zweck haben irgend ein Datum von oben nach unten durchzureichen, das ist aber ein Sonderfall - vielleicht mag man die Transportschichten (ISO/OSI-7-Schichtenmodell) so sehen. In einem Schichtenmodell übernimmt jede Schicht eine bestimmte Aufgabe, dies geht regelmäßig über das durchreichen eines Datums hinaus.

    Ich habe deine Fragen bereits beantwortet. Falls es da an Grundlagen zum Verständnis fehlt, dann hilft es vielleicht sich mit der Theorie zu beschäftigen, es gibt dazu einige Skripte und natürlich auch Bücher, zum Einstieg vielleicht das hier: https://dbs.uni-leipzig.de/buecher/DBSI-Buch/HTML/kap1-4.html

    Das dir Schnittstellen und deren Zweck nicht vertraut sind, kann ich mir nicht so recht Vorstellen, auch wenn dein Kommentar genau das impliziert. Es ist nicht erforderlich das eine Schicht Klassen einer anderen Schicht kennt, ein Anwender muss auch keine Klassen kennen um eine Software zu nutzen und die UI kennt auch keine Klassen des Anwenders (sie weiß nicht einmal was ein Anwender ist), die Interaktion erfolgt über die Schnittstelle, die dem Anwender durch die UI geboten wird -> Es ist für den Anwender transparent. Das nur als Anschauliches Beispiel, welches deutlich machen sollte warum nicht mehr bekannt sein muss als die dazugehörige Schnittstelle.


    - Gruß Florian


    Donnerstag, 1. Februar 2018 08:33
  • Hi Florian,
    ein Beharren auf der "absolut reinen Lehre" hilft dem Daniel bei der Beantwortung seiner Frage und seinem derzeitigen Wissensstand nicht besonders weiter. Ob man jetzt ein Datenobjekt als Klasse oder Interface beschreibt, ist für die Beantwortung von Daniels Frage von untergeordneter Bedeutung. Letztendlich werden Objekte vom Typ dieser Klasse oder Interface zwischen den Schichten ausgetauscht. Der Einfachheit halber kann die gleiche Spezifikation der Daten- bzw. Buseness-Objekte in allen Schichten genutzt werden. Und in diesem Fall müssen alle Schichten über Referenzen die Spezifikationen (Klassen oder Interfaces) kennen. Wenn sich jetzt wieder der Einfachheit halber diese Spezifikationen der Daten- bzw. Business-Objekte in der DAL befinden, dann muss die UI auch die DAL kennen (referenzieren). Um die Übersichtlichkeit zu verbessern, sollten diese Spezifikationen (Klassen bzw. Interfaces der Daten- bzw. Business-Objekte) jedoch in ein separates Klassen-Projekt ausgelagert werden. Dann ist es nicht notwenidig dass die UI die DAL kennt, sondern lediglich die dll mit den Spezifikationen.

    --
    Viele Grüsse
    Peter Fleischer (ehem. MVP)
    Meine Homepage mit Tipps und Tricks

    Donnerstag, 1. Februar 2018 09:03
  • Hallo Peter,

    ich habe die Diskussion darum nicht angefangen und auch im Grunde nicht führen wollen, du hast da Nachgefragt. Ich habe mich ausschließlich erkundigt warum es eine Abhängigkeit zu den Business Objects gibt, das hat mir Stefan dann ja bereits beantwortet und damit fand ich deine Eingangs gegebene Antwort bereits hinreichend.

    Warum der unerwünschte Verweis durch Visual Studio gesetzt wird, weiß ich nicht, vielleicht kannst Du ihm dies ja noch beantworten. Ich zitiere das hier nochmal:

    In dem Moment, wo ich in dem BLL Projekt den Verweis auf das DAL Projekt setze, und anschließend STRG+UMSCHALT+B drücke (also Projektmappe erstellen) DANN ist auch der Verweis in der Webanwendung (automatisch) auf die DAL gesetzt und ich kann logischerweise von den Webforms die DAL Methoden ansprechen (was ich eigentlich nicht will).

    Welchen Nutzen Daniel aus der Diskussion ziehen kann, kann und will ich nicht beurteilen, dass wird er selbst am besten können.


    - Gruß Florian

    Donnerstag, 1. Februar 2018 09:36
  • Hallo Florian,

    vorweg:

    ---

    Falls es dir bei deiner Aussage eigentlich nur um "keine Klassen (Class) verwenden, sondern Schnittstellen (Interface)" dann stimme ich dir in Teilen zu und wir haben wohl größtenteils aneinander vorbei geredet.

    "In Teilen" deshalb, da es auch Anwendungsfälle gibt, in denen es gar nicht anders geht. Bspw. in klassischen Webservices. Dort lässt sich in den Webservicemethoden für die Annahme und Rückgabe von Datenstrukturen nicht mit Interfaces arbeiten.

    ---

    Wenn es das nicht war, hier ein paar Worte dazu.

    Deine theoretischen Überlegungen sind sicherlich Ok, in der Praxis oft aber nicht so hilfreich wie Du dir das evtl. vorstellst.

    Natürlich übernimmt eine Schicht eine Aufgabe. Was das aber nun damit zu tun haben soll, dass eine Schicht nichts davon wissen darf/soll, wie die Daten-/Objektstruktur in einer darunterliegenden Schicht aussieht, erschließt sich mir nicht.

    Ich wollte von dir eigentlich nur eine Antwort auf die Frage: Wie kommen die Daten aus der Datenquelle ins UI und zurück wenn keine Schicht etwas von den Strukturen der anderen Schicht wissen darf? Dabei ist es völlig unerheblich, ob die Daten in ihrer Originalform oder x-fach über Schnittstellen in irgendeine andere Form gebracht werden. Das hast Du zwar schön umschrieben aber für mich hört sich das nach einer rein theoretischen Erklärung an, die in der Praxis wohl noch nicht umgesetzt wurde.

    Nur als Beispiel: Eine Datenbank hat eine Tabelle "Kunden" mit den Spalten "ID", "Kundennummer", und "Name". Wie soll in deinem Szenario die UI Schicht an diese Daten kommen, wenn weder UI noch BL überhaupt von deren Existenz wissen dürfen, da nur der DL das kennt. Es muss also irgendwo eine oder mehrere "Schnittstellen" geben, die diese Informationen vom DL nimmt und weiterreicht. Damit das geht, muss diese Schnittstelle wissen, welche Quell- und welche Zielstruktur verwendet werden muss.

    Ein Gegenbeispiel (für das das, was Du schreibst, problemlos anwendbar ist): Ein System soll unabhänig vm verwendeten DBMS sein. Also wird man den DL so aufbauen, dass er entweder universell mit allen DBMS zurechtkommt (eher unwahrscheinlich) oder man schreibt ihn so, dass die DB Zugriffe nochmal gekapselt werden und je nach DBMS bspw. über SqlConnection, OleDbConnection, OracleConnection, usw. gearbeitet wird.

    Natürlich kann man dann auch gleich hingehen und die gesamte Datenstruktur vollständig über den Haufen werfen und mit Mappings arbeiten, damit auch die Datenstruktur beliebig austauschbar ist, in der Praxis ist das aber eher ein Sonderfall und nicht die Regel.

    Es mag sein, dass Du wenig Erfahrung mit datenbankgestützten Anwendungen hast, was auch nicht weiter schlimm ist. Aber das Laden von Daten aus einer Datenbank und Weitergabe über ein oder mehrere Schichten an die UI und zurück (unabhängig davon ob nun in derselben Form oder in transformiertem Zustand) in der Praxis kein Sonderfall, sondern die Masse.

    Wie Daten von einem Layer zum anderen kommen, ist in den Schnittstellen zwischen diesen Layern definiert. Das Daten Layer stellt dem Business Layer eine Schnittstelle zur Verfügung, welche die Business Logik nutzt um sein Objekt mit den benötigten Daten, durch das Daten Layer, zu befüllen - es ist für die Business Layer transparent. Gleiches gilt zwischen UI Layer und Business Layer. Die Klassen der UI wissen nichts über die verwendeten Objekte des Business Layer und das Business Layer weiß nichts über die verwendeten Objekte des Daten Layer. Es werden keine Objekte durch alle Schichten gereicht.

    Letztendlich heißt das nichts anderes als das, was ich geschrieben habe:

    Die UI fordert vom BL ein Objekt an. Damit der BL der UI diese Objekt liefern kann, muss der BL wissen, welche Art von Objekt die UI eigentlich braucht. Zusätzlich muss der BL die Daten vom DL holen. Also muss auch der DL wissen, welche Struktur der BL braucht, alternativ muss der BL wissen, was der DL liefert.

    Ob das nun über eine Schnittstellen oder Klassen geht, ist dabei Nebensache. Auch Interfaces müssen irgendwo so definiert werden, dass alle beteiligten Schichten wissen, was benötigt wird. Oder die eine Schicht arbeitet eben direkt mit dem Objekt, was die darunterliegende Schicht erzeugt.

    ---

    Peter Fleischer: Wenn Datenklassen unsauber sind, dann negierst Du auch das EF? Oder das klassische ADO.NET mit dem typisierten DataSet?
    Florian Haupt: ich negiere gar nichts - beides sind auch keine Datenklassen.

    Das EF erzeugt reine Datenklassen bzw. werden diese definiert und für die Erzeugung der Datenstruktur sowie das Verwalten der Daten verwendet.

    ADO.NET arbeitet bei den typisierten Datasets ähnlich.

    Auch andere O/R Mapper arbeiten in der Regel nach diesem Prinzip.

    EF und ADO.NET sind natürlich keine Datenklassen. Sie produzieren und verwenden aber welche. Und das nicht zu knapp.

    Aber seis drum.

    So hat jeder seine Denkweise. Ich für meinen Teil beende das daher hier. Ich denke, es ist alles gesagt und dem OP nützt unsere Diskussion eh nix.

    Daher teile ich den Thread nachher noch auf, so dass man zur eigentlichen Frage des OP evtl. auch die Antwort finden kann.


    Gruß, Stefan
    Microsoft MVP - Visual Developer ASP/ASP.NET
    http://www.asp-solutions.de/ - Consulting, Development
    http://www.aspnetzone.de/ - ASP.NET Zone, die ASP.NET Community

    Donnerstag, 1. Februar 2018 12:12
    Moderator
  • Stefan,

    ich weiß nicht warum Du hier eine "Ich habe Recht und du nicht"-Diskussion versuchst zu führen. Vieles von dem was in deinem Text steht, was ich behauptet haben soll, habe ich überhaupt nicht geschrieben. Auf der Basis macht es auch keinen Sinn irgendetwas zu argumentieren, denn ich sehe mich nicht in der Pflicht Positionen zu verteidigen die ich nicht so aufgestellt habe.

    Und um es mal klar zu stellen, es geht hier nicht um "meine theoretischen Überlegungen", das haben andere überlegt, die sicher viel mehr Erfahrungen mit den unterschiedlichsten Softwarearchitekturen haben als ich diese habe. Ich schreibe hier also keineswegs von meiner persönlichen Meinung. Für mich ist das gelebte Praxis, mein Wissen darüber habe ich aus Ausbildung, Fortbildung und der entsprechenden Fachliteratur.

    Ich habe Dir mehrfach Links zur Verfügung gestellt, welche Schichtenmodelle behandeln. Im weiteren würde ich doch gerne davon ausgehen wollen, dass Du selbst in der Lage bist entsprechendes zum einen zu finden und zum anderen zu lesen.

    Wenn dein Wissen um solche Dinge zu eingeschränkt ist und Du zu wenig Lust hast dich damit auseinanderzusetzen, dann ist mir das Recht - ich möchte dies aber nicht zu meinem Problem machen.


    - Gruß Florian

    Donnerstag, 1. Februar 2018 13:35
  • Hi Florian,
    leider kann ich nur aus leidvoller Erfahrung sagen, dass die produktiven Projekte, die ich kennengelernt habe, weit weg von der "reinen Theorie" sind und trotzdem voll ihre Ziele erfüllen. Je komplexer ein Projekt ist (und ggf. noch arbeitsteilig entwickelt wird), um so wichtiger ist es, die Grundprinzipien der "reinen Theorie" möglichst umfassend anzuwenden. Bei kleinen Projekten rechtfertigt der Aufwand, der zu betreiben ist, meist nicht die zu erreichenden Ziele. Wie immer liegt als das Optimum irgendwo in der Mitte.

    --
    Viele Grüsse
    Peter Fleischer (ehem. MVP)
    Meine Homepage mit Tipps und Tricks

    Donnerstag, 1. Februar 2018 14:28
  • Hallo Peter,

    die Erfahrung teile ich und "leidvoll" trifft es oft. Sieht schon mal eher so aus wie in dem Comic:
    http://www.commitstrip.com/en/2016/02/15/our-companys-greatest-project/

    Ich denke auch das es eine Einzelfallentscheidung ist, welcher Aufwand gerechtfertigt ist. Darum werde ich auch nicht sagen, "Das muss so.".


    - Gruß Florian

    Donnerstag, 1. Februar 2018 14:48
  • ... Bei kleinen Projekten rechtfertigt der Aufwand, der zu betreiben ist, meist nicht die zu erreichenden Ziele. Wie immer liegt als das Optimum irgendwo in der Mitte.

    --
    Viele Grüsse
    Peter Fleischer (ehem. MVP)
    Meine Homepage mit Tipps und Tricks

    Danke, das nehme ich so mit und mache mir nicht mehr so 'nen Kopf... Es funktioniert ja grundsätzlich :-D

    Danke für eure Antworten, ich fand den Ausflug in die Theroie und eure sichtweise anregend!

    Beste Grüße

    Daniel

    Montag, 5. Februar 2018 16:14