In dem Buch Java Open Source Programming im Kapitel 6: Model View Controller with WebWork beschreiben die Autoren das MVC Muster als Mittel um eine Anwendung in Schichten aufzuteilen. Zu der Modellschicht (Model Layer) schreiben die Autoren:

Die Modellschicht repräsentiert die Geschäftsdomäne. Sie erfüllt zweierlei Aufgaben:

• sie ermöglicht den Zugriff auf die Anwendungsdaten. Z.B. Listet sie die Produkte im Inventar auf.
• sie erlaubt den Zugriff auf die Geschäftslogik; wie z.B. das Kaufen eines Produktes

Als Beispiele der Implementierung des Modellschicht führen die Autoren Java Objekte, Enterprise Java Beans, Stored Procedures, Web Services und CORBA Sevices auf. (Swing-Modelle jedoch nicht, dass würde in das Schichtenschema nicht reinpassen)

Weiter beschreiben sie zwei wichtige Designregeln, die man beachten soll:

• Auf alle vom System benötigen Interaktionen und Daten sollte über das Model zugegriffen werden.
• Das Model sollte überhaupt keine Ahnung über die Benutzerschnittstelle haben. ...

Obwohl ich die Schichtenarchitektur für sehr vernünftig halte, habe ich meine Probleme mit der Beschreibung aus dem Buch. Ich behaupte, dass die Autoren das Muster Model-View-Controller mit der Schichtenarchitektur verwechseln. (Presentation Manager, Presentation Logic, Application Logic, Data Logic und Database Management).

Das, was die Autoren als „Model Layer“ bezeichnen, entspricht der Application Logic-Schicht in der Schitenarchitektur. Das MVC-Muster wird aber meistens in der Benutzerschnittstelle (in der Präsentationsschicht) verwendet. Sie vermischen also zwei unterschiedliche Anliegen der Anwendung - die Darstellbarkeit und die Geschäftslogik.

Nach meinem Verständnis des MVC-Musters, repräsentiert das Model „das Dargestellte“. Das können durchaus die Objekte der Geschäftsdomäne sein, müssen aber nicht. Die wichtigste Aufgabe des Modells ist also nicht den Zugriff auf die Geschäftslogik zu ermöglichen, sonder einfach darstellbar zu sein.

Die Aufgaben, die die Autoren der „Model Laywer“ zuweisen, sollten die Fachdomänenobjekte in der Geschäftslogikschicht erfüllen - und diese sollte tatäschlich keine Ahung über die Benutzerschnittstelle oder deren Vorhandensein haben.

Die Darstellbarkeit der Fachobjekte - deren Modellsein sollte aber in der Präsentationsschicht implementiert werden. Die Implementierung des Modellseins kann dabei sehr einfach sein - In einer Swing-Anwendung kann z.B. die Fachklasse Bestellung durch eine Klasse, die die Schnittstelle TableModel implementiert, als Tabelle darstellbar gemacht werden. Eine andere Implementierung kann TreeModel implementieren und so eine baumartige Darstellung ermöglichen. Oder man kann eine spezialisierte Viewklasse schreiben, die eine Bestellung ohne Adapter darstellen kann und so die Fachklasse implizit zum Modell macht.

In jedem Fall sollte man aber die Anliegen: Geschäftslogik und Darstellbarkeit (Modellsein) konzeptionell auseinander halten. Sonst käme man viel leicht später noch auf die Idee die persistente Datenhaltung, oder die Sicherheit, oder was auch immer in die „Modellschicht“ zu integrieren. :-)

Über die Schichtenarchitektur kann man mehr z.B. in dem Buch High-Performance Client/Server erfahren.