[Asp.Net 2.0] 3-Layer oder Databinding
Guten Morgen (bzw. Mittag),
ich bin gerade an einem Punkt angekommen wo ich net mehr weiter weiß:
Relativ oft findet man Aussagen darüber, dass das 3 (oder n)-Layer Design "besser" ist. Also flexibler ect.
Genauso oft findet man aber auch, dass das neue Databinding bei Asp.Net 2.0 super sei...
irgendwie verstehe ich das nicht!
Das neue Databinding (also SqlDataSource und dann einem DataBound-Control zuweisen) ist nicht wirklich (bzw garnicht) im Layer Design, aber beide Techniken werden hochgelobt...
gibts eine Möglichkeit beide Techniken gemeinsam zu nutzen (also mir würde da nur einfallen, dass ich die DAL und BLL normal aufbaue und dann das Result an das DataBound-Control binde...aber das gefällt mir nicht so wirklich (dann nehme ich doch lieber den einfacheren Weg mit dem DataSource-Control))
oder welche Technik sollte man bevorzugen (und warum!)
hoffe ihr könnt mir helfen (gerne auch mit Links)
Ich würde sagen, das hängt ziemlich von der Art des Projekts ab.
Sehr spezielle Anwendungen und/oder welche, bei denen keine Änderung der Datenhaltung vorgesehen ist, können sicher auch unter Verwendung des DataBinding entwickelt werden.
Ansonsten halte ich das Provider-Prinzip für die Top-Design-Lösung, wobei das natürlich einen erheblichen Mehraufwand an Arbeit bedeutet. Man muss da schon genau abwägen.
Grüsse
Cord
Hallo,
um beides zu Verbinden gibt es die ObjectDataSource, der man ein Businessobjekt übergeben kann, dass natürlich bestimmte Funktionen besitzen muss, wie eine Select, Insert, Update oder/und Delete Funktion.
Ansonsten kommt es auf die Größe des Projektes an, ob man mehrere Schichten verwendet oder eher monolithisch arbeitet.
Ein guter Ansatz wäre PWA, dazu gibt es von Patrick A. Lorenz 5 Webcasts auf MSDN
MSDN - PWA
Ansonsten gibt es bei der Practices and Patterns Gruppe zahlreiche Ratgeber.
Mfg,
Jens
Original von altertoby
2. Genauso oft findet man aber auch, dass das neue Databinding bei Asp.Net 2.0 super sei...
Wenn du einen Monolithen bauen willst ja, ansonsten ist das alles Schrott. Der Code hat anschließend die Wiederverwendbarkeit einer Einwegpfandflasche.
gibts eine Möglichkeit beide Techniken gemeinsam zu nutzen (also mir würde da nur einfallen, dass ich die DAL und BLL normal aufbaue und dann das Result an das DataBound-Control binde...aber das gefällt mir nicht so wirklich (dann nehme ich doch lieber den einfacheren Weg mit dem DataSource-Control))
Ja, ObjectDataSource. Klappt ganz gut.
oder welche Technik sollte man bevorzugen (und warum!)
Ein Thema, auf das du 10 Antworten bekommen wirst, wenn du 9 Leute fragst. Es gibt wirklich viele unterschiedliche, mehr oder weniger abstrakte oder pragmatische Ansätze.
Ich habe für mich derzeit als Lösung für die meisten Anwendungen im Webbereich nen ganz einfachen Ansatz gefunden, der im Prinzip aus 3 Namespaces besteht.
- Business Objekte
Hier definiere ich einfach meine "Objekte", oder um weniger abstrakt zu sein, z.B. das Objekt vom Typ Kategorie. Lege also die Klassen mit ihren Eigenschaften an.
- Datenzugriffsschicht
Für jeden "Bereich", z.B. Kategorien, hier die entsprechenden Methoden für Update, Insert, Delete usw. Der einzige Ort in der ganzen Applikation, in der Datenbankcode steht. Kann man so aufziehen, dass man unabhängig von der DB ist, was zumindest für MySQL, SQL Server und Oracle mit Stored Procedures funktionieren könnte.
- Business Layer
Hier verschmilzt bei mir noch zu viel Frontend mit reiner Geschäftslogik, aber das ist ein Leid begründet im Design von ASP.NET. HIer müsste eigentlich alles passieren, was die App steuer, also auch Validierung usw. Da das aber bereits in ASP.NEt integriert ist, und ich das Ganze nur fürs Web baue, spare ich mir das.
Hallo,
ich habe in meinem letzten ASP.NET Projekt folgende Struktur verwendet:
1. Schicht Domain-Objects (so habe ich sie zumindest genannt):
Hier werden die applikationsspezifischen Klassen mit all ihren Eigenschaften und Verknüpfungen untereinander definiert, wie zum Beispiel die Klasse Kunde, die Klasse Auftrag, Auftragsposition, etc.
**2. Schicht DAL (Data-Access-Layer) **- baut bei mir auf NHibernate auf:
Hier habe ich den reinen Datenzugriff gekapselt. Also ausschließlich Speichern, Laden, Löschen. Dazu habe ich mir eine generische DAO<T>-Klasse geschrieben, welche ein Datenzugriffsobjekt für eine meiner Domain-Classes darstellt. Dann habe ich für jede meiner Domain-Classes eine eigene Datenzugriffsklasse abgeleitet, in der zum Teil noch ein paar zusätzliche Methoden (zum Filtern, etc.) enthalten sind.
Beispiel:
public class OrderDAO : DAO<Order>
{
public IList<Order> GetOrdersForCustomer(Customer customer)
{
....
}
}
So habe ich die Kernfunktionen komplett in der generischen DAO<T>-Klasse gekapselt. Wenn ich jetzt also meinen ORM wechseln möchte, kann ich ihn in der generischen Klasse auswechseln und dann läuft es (fast überall).
3. Schicht Business-Logik:
Hier habe ich sogenannte Controller-Objekte, welche mir einzelne Use-Cases implementieren. Zum Beispiel gibt es einen Controller, um Aufträge anzulegen. Hier werden dann auch Prüfungen gemacht, welche Werte zugewiesen werden dürfen, welches der aktuelle Auftrag ist, etc. Zusätzlich gibt es hier Methoden, die unterstützen, wenn man z.B. Auftragspositionen hinzufügen, verschieben, o.ä. möchte.
4. Schicht Darstellung:
Hier liegen die ASP.NET-Seiten. Jede Seite (die es braucht) hat ein Controller-Objekt zugewiesen, welches auf bei Postbacks erhalten bleibt. Somit habe ich die Logik ziemlich vollständig aus der Seite herausgeholt. Ich verwende überall Datenbindung: für Gridviews nutze ich meistens ObjectDataSources, welche mit den entsprechenden DAO-Objekten verbunden werden.
Wenn ich aber z.B. eine Form habe, in der ein Kunde bearbeitet wird, habe ich das Controller-Objekt, welches eine Eigenschaft "Kunde Record" hat, mit der ich arbeiten kann. Hier verwende ich dann Datenbindung direkt mit der Controller-Objekt-Property anstelle von ObjectDataSource-Datenbindung.
Das ganze funktioniert für mich grundsätzlich absolut prima. Das einzige Problem, das ich habe ist zurzeit Performance, da meine Domain-Objects ziemlich komplex sind und NHibernate damit nicht so gut klarkommt. Aber ich denke, dass ich da sichlerich noch tunen kann. Vom Aufwand hat es sich aber sicherlich gelohnt, eine solche Architektur aufzubauen - es ist jetzt denkbar einfach, das System zu erweitern...
Viele Grüße!
ui das hat mich jetzt positiv überrascht soviele (ausführliche) Antworten zu bekommen - thx!
Also meine Architektur ist DAL (nur Datenbankzugriff und die letzte Validierung (z.B. zu große Daten)), dann die BLL (hat eigentlich bisher nicht wirklich eine Funktion...validiert ein wenig aber gibt sonst meist nur die Parameter weiter...Funktion kommt aber sicher, wenn dann die benötigten Funktionen steigen) und dann zum Schluß noch das Fronted.
Da sind mir jetzt auch wieder ein paar Fragen aufgetaucht:
DAL:
Bisher hab ich da als Return-Values meist string, int, bool, ect oder meine eigenen BLL-Objekts gehabt. Bei MSDN hab ich aber gelesen gehabt, dass man für besseres Paging und Sorting lieber ein Typed-DataSet nehmen sollte...
da ich bisher auch gut ohne DataSets ausgekommen bin hab ich nur für Fälle, wo ich die Absicht hab an eine GridView o.ä. zu binden ein DataSet verwendet (bzw will ich verwenden). Die Frage ist jetzt wie weit ich das DataSet ausbauen soll...also soll es wirklich nur die Select-Anweisung kapseln oder noch mit Insert, Update und Delete ausgestattet werden...oder dass dann lieber alles ohne DataSet machen??
Die 2. Frage ist, wo ich am Besten Validierungen a la "Wenn der User das Recht hat, dies zu machen, darf er es machen, ansonsten nicht"
in der BLL würde es meist einen zusätzlichen Round-Trip zur DB zur Folge haben (Hat er das Recht oder nicht) aber die Validirung erst in der Stored-Procedure zu machen gefällt mir auch nicht (wegen Wiederverwendbarkeit)
Bitte dazu auch wieder so hilfreiche Antworten! thx nochmal und im Vorraus
Nur keine Typed Datasets! Du bist schon auf dem richtigen Weg - Paging, Sortierung usw. kannst du auch locker für deine eigenen Objekte implementieren, am einfachsten, wenn du generische Listen verwendest.
Beispiel für ne Liste von Ländern (Pseudocode):
public static List<Country> GetCountries(string culture)
{
List<Country> countries = new List<Country>();
//
return countries;
}
Typed Datasets sind dermaßen aufgebläht und unperformant, dass ich sie wirklich nur benutzen würde, wenn es schnell gehen muss.
Zu 2.: Das gehört eigentlich alles in den Business-Layer.
@archimedes: interessante Sache. Du kannst nicht mal eine Sample-App zusammenstellen, wenn du Zeit hast?
Yup, DataSets haben in Web-Anwendungen nichts zu suchen. Keine Ahnung, warum sie in so vielen MSDN-Examples verwendet werden. Bei Desktop-Apps, wo man Werte aktualisiert und rückschreibt, ist das okay, aber für die Einmalige Verwendung des Auslesens sind sie definitiv zu inperformant.
DB-Zugriffe machen locker 90% oder mehr der Zykluszeit im Web aus, da muss man optimieren, wo's geht. Daher sollte man nur mit DbCommand und DataReader arbeiten.
Paging kannst Du auch über SQL-Statements realisieren.
Grüsse
Jup ich bin nach einem MS-Example gegangen und da wurden nur getypte DataSets als DAl verwendet.
Also ich hab gerade nochmal alles überarbeitet und eine weitere Schicht eingefügt (als unterste), da wo alle Objekte (Kunde, Product, ect) beschrieben werden.
Das war bisher alles in der BLL, aber so musste der DAL auf die BLL zugreifen um den richtigen Typ zurück zu geben.
Naja aber irgendwie hab ich hier unendlich viele Fragen 🙂
noch eine:
Wie macht ihr das, wenn ihr nur einen Teil eines Objektes braucht?
Also am Beispiel:
Objekt Kunde mit Adresse, Telefon Nummer, ectpp aber man braucht jetzt angenommen nur die Telefon-Nummer und die Adresse ist völlig egal!
Die Frage ist nun ob man dafür dann eine eigene Stored Procedure (GetClientPhoneNumber) machen sollte oder lieber mehr von einer algemeinen SP zurückgeben lassen (GetClient) und dann eben nur mit der Telefon-Nummer arbeitet?
Also die 2. Möglichkeit dürfte unperformater sein, aber die 1. ab einem bestimmten Punkt sicher reichlich kompliziert (wenn man irgendwann mal 200 Spalten hat und immer mal wieder nur eine braucht).
oder gibts noch eine 3. Möglichkeit?
Warum sollte die zweite Lösung unperformanter sein? Die Datenbank musst du doch eh öffnen. Ob du nun ein Feld oder mehrere ausliest, sollte in diesem Fall egal sein.
In deinem Beispiel würde ich die zweite Lösung bevorzugen, allerdings gibt es Anwendungsfälle in denen die erste Lösung "besser" ist.
Das kann man nach eigenem Geschmack handhaben, aber irgendwann wird es halt nervig, wenn man 100 verschiedene Methoden für jede einzelne Eigenschaft hat.
Und wie Kai schon sagt, es ist von der Performance her völlig wurscht, ob du 1 oder 20 Werte aus der Datenbank ausliest und dem Objekt zuweist, zumindest wenn es sich um "normale" Datentypen handelt, und du nicht megabyteweise Daten hin und her schaufeln musst.
sicherlich dürfte die Performence beim Sql-Server sich kaum verändern. Aber da ja insgesamt immer wieder mehr Daten versendet werden (im Extremfall vom Sql-Server auf einen anderen Server wo dann die DAL läuft)
ich dacht mir nur, da mehr Daten ausgelesen, versandt werden und dann eigentlich untern Tisch fallen, dass dies nicht umbedingt die performateste Lösung sein sollte!
EDIT: ok glaub ich euch das einfach mal dass die Performance kaum benachteiligt wird und vom Aufwand her ist es auch viel weniger Arbeit freu
Den SQL Server ans andere Ende der Welt zu stellen, solltest du sowieso bleiben lassen ...