Model-View-Controller

Model-View-Controller is a widely used Architectural Pattern. The program is split into three Components. The Model contains the program state, the Controller executes user actions and the View displays information for the user.

Model-View-Controller Architecural Pattern.

This pattern is not quite compatible with LISA.

The Domain Language is implemented in the Model.
The Application is split between the Model and the Controller
The User Interface is split between the View and the Controller.
The View implements two Languages, the User Interface for the user and the View Control for the Controller.

This leads to the following drawbacks:

It is not feasible to reuse any of the Components. The only possible candidate is the Model, but it is neither a clean Domain Language, nor a complete Application. Languages are reusable, not Components.
A change to the requirements are likely to affect most of the components at the same time. The structure is not flexible.
Parts of the Application implementation depend on the User Interface.

Here is a possible Language inheritance graph for a web application implemented with Java servlets.

Model-View-Controller Language inheritance graph.

MVC is monolithic and not made for reuse. The entire structure is basically one Language, and as the Language mainly interacts with the user, the conclusion is that MVC is just a large User Interface and Application mixed together with a polluted Domain Language at the bottom. This kind of messy architecture is what LISA is built to avoid. The pattern may feel intuitive when looking at it from a functional breakdown perspective, but when looking from the Language definition perspective, it doesn't make sense.

Note that MVC's ability as a Design Pattern is not examined here. Upon examination, it may turn out to be a good Design Pattern, or similar deficiencies will be detected in this domain as well.

MVC improved

With some minor modifications, MVC can be transformed into a better pattern, retaining the qualities the original pattern tried to offer. The architect considering MVC wants to have multiple views and controllers interacting with the same Application. The conclusion above was that the controller and the view can't be separated in a clean way. The solution is to let any Component interact with the Application, and combine view and controller functionality in the same Component when necessary.

Model-View-Controller improved.