Ich bin mal so frech und zitiere hier direkt Fredrik Normén’s Beitrag aus seinem Blog. Er hat es nämlich satt, dass die Business-Logik-Schicht oft falsch verstanden, vernachlässigt und zum Teil falsch eingesetzt wird. So Fredrik, hier deine Worte im Englisch. Ich bin mir sicher, dass ihr es verstehen werdet.
Controllers in the MVC pattern is not a replacement for Business logic layer
I have seen several demos and examples on presentations where the Controllers are more or less used as a Business logic layer and based on the definition of the MVC Pattern, that is not the correct way of using the Controller. The Controller in the MVC is not a replacement of the Business Logic Layer. The Model in the MVC is the Business Logic Layer. The Controllers purpose is to be a contract between the View and the Model, and handle user actions. Think of the Controller like the Web Form’s Code-behind, the logic you put in the code-behind can sort of be added to the Controller, the benefit you get by using MVC over Web Forms is that you can now with the MVC write unit test to test „complex“ presentation layer code, and it’s not easy to write test against the code-behind because it’s event driven.
The correct design when using the MVC would be:
Presentation (View) -> Controller -> Business Logic (Model) -> Data source
When using the Domain Driven Design, the Controller will work against the Service/Application Layer or the domain model, if we work with a old traditional n-tier architecture, the Controller will work against the Business Logic Layer.
Ich verstehe zwar den Punkt, habe aber bisher selbst nur gesehen, dass die Business Logik in den Controller gepackt wurde, von daher würde ich gerne mal einen Sample Code sehen (jetzt nicht pro forma sondern am besten aus einer „echten“ Anwendung (z.B. kleiner Blog)) wo man sich das mal am Beispiel ansehen kann.
@Sebastian: Ich versuche mal das Ganze hier erst mal komplett Aufzuklären und gehe dann konkret auf deine Frage ein.
Präambel
In einem drei-schichtigen Client-Server-System wird die Software nach ihrer Funktion in drei Ebenen unterteilt:
1. Daten-Basis: Die Datenschicht ist die unterste Schicht. Sie besteht aus der Datei-Ebene und umfasst die reine Datenhaltung, meist eine Datenbank.
2. Anwendungsschicht: Die zweite Schicht, die Anwendungs- oder Geschäftsschicht, ist für die Bearbeitung der Daten verantwortlich. Diese Schicht beinhaltet Programme, die Daten und Informationen aus der untersten Schicht verarbeiten und für die Darstellung in der Präsentationsschicht vorbereiten.
3. Benutzeroberfläche: Die als Präsentationsschicht bezeichnete dritte (oberste) Schicht liefert die Schnittstelle zum Anwender und beinhaltet alle Komponenten zur Präsentation der Daten.
Die „Business Logic“ bildet also die mittlere Schicht des Drei-Schichten-Modells, die Anwendungsschicht. Sie ist in der Regel auf einem (oder mehreren) Server des lokalen Computer-Netzes (LAN) des Unternehmens gespeichert. Die Geschäftsschicht fungiert als Server für die Anfragen der Clients auf den angeschlossenen Arbeitsplatzrechnern. Die Software der „Business Logic“ ermittelt, welche Daten benötigt werden und wo diese zu finden sind. Die „Business Logic“ fungiert als Client im Verhältnis zur untersten Ebene des Drei-Schichten-Modells, also zur Daten-Basis.
Zurück zum Artikel und deine Frage.
Es kommt sehr oft vor, dass man die komplette Geschäftslogik direkt im Controller erstellt. Das funktioniert auch, kein Thema. Aber diese Geschäftslogik kann nicht wieder verwendet werden und ist nicht leicht zu Testen, da der Event erst erstellt werden muss. Hier würde man an besten die Geschäftslogik in einer Facade- oder Helperklasse auslagern, und soweit aufbauen, dass sie leicht wieder zu verwenden und zu testen ist. Im Controller wiederum würde man die Facade aufrufen. Man versucht also einen schlanken und übersichtlichen Controller zu halten, dafür aber eine fette, sichere und flexible Geschäftslogik.
Näh. Das liegt daran, daß „MVC“ nicht fürs Web gemacht ist, sondern als aktive Runtimestrukturiereung für graphische Anwendungen gedacht war.
PHP Frameworks verwenden das nur als Buzzword. Was oftmals umgesetzt wird heißt korrekterweise „Passive-MVC-2“ oder „Model-View-Presenter“. Es wissen halt nur die wenigsten.