Does the MVC pattern describe Roles or Layers?

Question

I read a text recently saying the MVC pattern describes the layers in an application. But personally I see MVC showing several key roles in an application.

Which word do you think is better, layer or role, to describe the three main pieces of MVC?

Answer 1

Why not Both? I see it as 3 separate layers implementing 3 different roles.

Answer 2

You cannot compare those two words, because they describe different concepts. To me, a layer is something opaque that offers some functions I can use to do things. For example, a good hardware layer for a wireless transmitter would just give me a send and a receive-function (based on bytes, for example), hiding all the ugly, ugly details from me.
A role is a way an object will behave. For example, a transformation in one of my compilers is going to take an abstract syntaxtree and return an abstract syntaxtree or an affection in my current project is going to take a state-difference and return a specifically altered state-difference.

However, coming with those two definitions, I do not see the need to chose a single "correct" term and burn the other as wrong, because they don't conflict much. A part of a layer has a certain role, and a set of objects conforming to certain roles form a layer. Certainly, the controller forms a certain layer between the UI and the model (at least for input), however, ot also has a role - it turns certain event into certain other events (and thus, it is some sort of adapter).

Answer 3

I think roles is a better description. The view and the controller are both in the same "layer" and usually the model is described as a layer but is used between layers.

Usually my applications are centered around the domain model with stuff like presentation, persistence and file-io around it. Thinking about an architecture as layered doesn't really work for me.

Answer 4

I think either can be reasonably argued for, but I think describing the parts as "layers" is more consistent with other conventions, like the OSI model. Since the View, Controller, and Model get progressively closer to your data, it's more of a layered structure. It seems that "roles" would apply to different parts of an application on the same layer.

Answer 5

Layers should imply a very narrow coupling between the respective sets of code. MVC involves relatively tight coupling between the model, view, and controller. Therefore, if you characterize this as a layering pattern, it becomes problematic in terms of defining an API between the layers. To do this properly, you would have to implement some unintuitive patterns.

Because of this, I would agree with your tendency to view it as a pattern that defines roles within a single layer.

Answer 6

It's all terminology, but I think the correct software architecture term would be "layer", as in logical layer. You could use the term "architectural layer" if it is clearer.

The thing is, it's just a different way of slicing an application: a classic n-layer app would be:

• UI
• Business Logic
• Persistence

You could have the following logical layers in a simple MVC application:

• UI
• Controller
• Model
• Persistence

But you could still talk about the "UI" and "Controller" together as forming the User Interface layer -- I usually split out the Controller into a separate layer when describing and diagramming these architectures, though.

Answer 7

MVC clearly defines ROLES. these are 3 roles you can implement in any number of layers. For example u can have a multi layer controller

Answer 8

Roles, not layers. Layers are completely dependent on the underlying implementation of the MVC pattern. For instance, a service layer may be a single layer on one implementation, but it could have a web service remoting layer and a database layer (for two differing service layers) on another implementation. The concept of layers is just to help you organize it, as is the pattern, but layers are not as easy to spot as patterns, and layers can change, whereas the pattern remains the same despite the layers changing due to different implementations.