I was originally going to make this a longer question, but I feel like the shorter I make it, the better you’ll understand what I mean.
-
The MVC architectural pattern has 3 dependencies. The View depends on the model. The Controller depends on the View and Model. The Model is independent.
-
The Layers architectural pattern defines N – 1 dependencies, where N is the number of Layers.
Given three Layers: Model, View, and Controller, there are only 2 dependencies, as opposed to 3 with traditional MVC. The structure looks like this:
View ---> Controller ---> Model
[View depends on Controller, Controller depends on Model]
It seems to me that this style accomplishes the same goals and produces looser coupling. Why isn’t this style more common? Does it truly accomplish the same goals?
Edit: Not ASP.NET MVC, just the pattern.
With regard to griegs’s post:
- As far as mocking, Layers still allows you to use the Command Processor pattern to simulate button clicks, as well as any other range of events.
- UI changes are still very easy, perhaps even easier. In MVC, the Controller and View tend to mesh together. Layers creates a strict separation. Both Layers are black boxes, free to vary independently in implementation.
- The Controller has 0 dependencies on the View. The View can be written, and time can still be saved with loose coupling.
I haven’t gotten back to this in a long time, mostly because I was still thinking. I was unsatisfied with the answers I received, they didn’t really answer my question.
A professor, recently, did steer me in the right direction. Essentially, he told me this: Layers which separate Model, View, and Controller is MVC. In the vanilla MVC architectural pattern, the dependency between the View to the Model is often not used, and you effectively end up with Layers. The idea is the same, the naming is just poor.