(ASP.Net) MVC Pattern - von wo greift man auf die DB zu?

[Gast]

Hi,
ich bin gerade dabei C# zu lernen (also nicht schlagen wenn ich was verdrehe, bin noch ein noob) und versuche hierbei eine Webanwenung zu schreiben. Hierbei verwende ich das ASP.Net MVC 3 Framework.

Was ich dabei aber nicht ganz begreife ist, von wo ich auf meine Daten zugreifen sollte (DAL)...?

Im Internet (hauptsächlich im Stackoverflow Forum) wird es mal so beschrieben, dass man vom Controller auf die DB zugreift, die Informationen in ein Model steckt und dieses dann der View übergibt.
Andere machen Ihre Queries direkt im Model. Andere verschieben das ganze wiederrum in eine völlig neue Schicht (Service layer) und greifen dann vom Controller auf den Service zu...


Wie macht man es nun am besten? Nehmen wir mal folgendes als Beispiel:

- Ein User kann auf der Weboberfläche Bucheinträge anzeigen lassen, sie löschen/bearbeiten und neue Einträge hinzufügen.

Ich würde es Intuitiv so machen:
- die View ist an ein Model Books gebunden
- Books ist ein simples Object, welches nur eine Liste von Book darstellt
- Book besteht nur aus get und set Methoden bzw. Properties - sonst nichts
- der Controller greift beim laden auf die Data Access Schicht zu und füllt das Books Model mit Informationen und übergibt diese an die View
- bei allen Arten von Änderungen (Add, Edit, Delete) delegiert wieder Controller die Änderungen an den DAL.
also z.B.
BookRepository.Add(bookAuthor, bookTitle, ...)
BookRepository.Edit(bookId, newAuthor, newTitel)
BookRepository.Delete(bookId)

Bei mir steckt also die ganze logik direkt im Controller. Ist solch eine Verwendung des MVC Patterns richtig?

[Frucht-Tiger]

Bei einer Logik die nur aus wenigen Zeilen besteht, kann man das schon so machen, grundsätzlich verstößt das nicht gegen das MVC-Pattern. Natürlich würde es die Wiederverwendbarkeit steigern, wenn du auch die Anwendungs-Logik in eine weitere Schicht verlagerst. Kein Browser-Client mehr sondern Zugriff über Webservices? -> Neuer Controller her. Statt Datenbank speichern in eine XML-Datei? -> einfach DAL austauschen. Die Anwendungs-Logik bliebe jeweils unberührt. Die Business-Logik würde man dann in einer weiteren Service-Schicht ausprogrammieren, die wiederum auf die DB-Schicht zugreift.

Gerade bei nicht so komplexe Anwendungen finde ich auch das Active Record Pattern sehr attraktiv. Hierbei erhält das Model selbst die Ausführungslogik um sich in die Datenbank zu schreiben, damit würdest du den Controller von allen Datenbankabhängikeiten befreien(dafür sind die dann natürlich beim Model zu finden, hier auf jeden Fall mit Vererbung arbeiten). So würde das auschauen:

Book newBook = new Book("G.R.R. Martin", ....);
Book.save(newBook);
Book danceWithDragons = Book.findByAuthor("G.R.R. Martin");

Vorteil dieser Technik ist das du mehr in richtigen Objekte programmierst, da die Model-Klasse jetzt sowohl einen Zustand als auch Verhaltensweisen des Models enthalten kann: alle "Bücher-Aktionen" werden auch in der Book Klasse gekapselt. Vorher hattest du nur Nicht-Objekte: das Model speicherte nur Zustände, das BookRepository, der Controller und die evt. Service-Schicht bilden nur Verhalten ab: das ist nicht im Sinne von OOP(wird aber in der Praxis sehr häufig so gemacht)

Es gibt auf jeden Fall viele Möglichkeiten das Problem zu lösen, dein Ansatz ist nicht "falsch", je nach Situation wäre er für mich "richtig" und umgekehrt. Viel Spaß :D

[Monger]

MVC ist ja eine 3-Tier Modell. Da kommt Datenhaltung konzeptionell gar nicht vor.

Wenn ich an 4-Tier denke, dann sitzt die Datenhaltung normalerweise unterhalb des Controllers. Irgendwas muss ja schließlich das persistieren triggern: entweder ein Click auf "Speichern", oder ein Timer etc. etc.

Dass JEDE Transaktion automatisch und sofort hinten in der Datenbank landet ist zwar auch eine Möglichkeit, aber grundsätzlich sollte definiert werden, über welche Wege und auf welche Weise das Model mit der Datenhaltung reden sollte. Bei vielen kleineren Applikationen ist die Controllerschicht ohnehin hauchdünn.

[Gast]

Es gibt auf jeden Fall viele Möglichkeiten das Problem zu lösen, dein Ansatz ist nicht "falsch", je nach Situation wäre er für mich "richtig" und umgekehrt. Viel Spaß :D
Ja, "leider".
Es ist für einen Anfänger kaum zu verstehen, wenn es da keine Best Practise gibt.

Nach weiteren Stunden googlen, scheint es mir, dass die meisten doch eher dazu tendieren, den DAL 'unter' das Model zu hängen. Da bietet sich auch das genannte Active Record Pattern bestens an.

Wenn ich nun die Geschichte richtig verstanden habe, dann wird es so aufgebaut:

Aus dem MVC Pattern: C -> M, C -> V -> M wird dann

C -> M -> DAL
C -> V -> M

So, wo steckt dann aber die ganze Business Logik drin?

C -> V -> M
C -> M -> BLL -> DAL?

[Ganon]

Naja, deine Logik kommt zwischen der Aktion und dem Speichern. Wenn der Nutzer eine Änderung in der Oberfläche machst und du auf Speichern klickst oder wie auch immer, kriegt das ja der Controller mit. Dann musst du entsprechend der Aktion deine Logik ausführen und das Ergebnis speichern.

Kommt jetzt natürlich darauf an wie du das machst. Bei ActiveRecord wird afaik das Model gespeichert, was dann wiederum die Logik aufruft und dann speichert. Das ist da etwas "wirr" auf den ersten Blick ;)

[xxxgamerxxx]

MVC ist ja eine 3-Tier Modell. Da kommt Datenhaltung konzeptionell gar nicht vor.


Das hat eigentlich nichts mit Tier zu tun. MVC ist logisches Layern, wo hingegen n-Tier eher n physikalische Grenzen meint. Webanwendungen sind i.d.R. klassische 3 tier Modelle -> Client (Browser), Web Server, DB Server

Du könntest auch das MVC Pattern in einem Fat Client, also ein klassisches 2-tier Modell implementieren.

[creave]

MVC ist eigentlich kein Schichtenmodell im eigentlichen Sinne denke ich. Die Logik und das Datenmodell sind im Model angesiedelt, wobei der Datenzugriff durch MVC nicht geregelt wird, sondern nur die Manipulation des Models durch die GUI (bzw. durch Controller). Es spricht wohl nichts dagegen, sich "darunter" einen üblichen DAL zu bauen.

Ich denke, dass das aber nicht so übermäßig strikt gehandhabt wird, auch nicht bei MVC3. Dort lässt es sich ja gar nicht vermeiden, ViewModels als Vorstufe zum eigentlichen Model zu bauen. Und da man das Model bei Ausreizung des Frameworks mit Framework-spezifischen Sachen "pollutet", überlegt man sich vielleicht, auf "DRY" zu schei... und für jeden abzubildenden Sachverhalt vielleicht mehr als nur DIE eine Modelklasse anzulegen.