We just started working with Sinatra which uses the MVC (model–view–controller) pattern to implement a user interface. It is broken up into 3 main components:
The Model: The logic of an app where data is changed or saved.
The View: The front facing part, where the user can input data or click on a button in order to get information from the app.
The Controller: The go between for the model and the view. It takes the users request to the model and serves up the results back to the user.
The separation of these components allows for efficient code reuse and parallel development making the app easier to manage for the developer.
So what is the difference between MVC and other design patterns I wondered?
My first search brought me to this blog which seemed pretty helpful and straight forward:
I wanted to break this down a bit and explain it more clearly if possible, so I headed over to Wikipedia for some more insight on the issue.
They each had their own definition and seemed similar in certain ways and slightly different in others. The graphical representations didn’t help much. I noticed the MVP looked nearly identical to what we learned about MVC, where the controller acts as a go between for the model and view, the presenter performs the same function.
Ok. Stack Overflow should be able to clear this up…
There are so many diagrams and discussions in this thread. And every user seemed to have caveats to each definition another presented. Also, this is not the only thread in Stack Overflow on this topic.
From what I could gather, it seems that MVC and MVP are similar except the with MVP, each view (usually) has its own presenter, where as with MVC a controller can mediate between several views and models. Having worked with MVVM (Knockout.js) a bit, it seems the view model replaces the controller/presenter and acts as a binder which represents the state of data in the app. The view model updates the data immediately in the view without a page change or refresh. The one common thread in all of these patterns is the view and model should never communicate directly with each other.
My take away is which ever architectural pattern you are working with, learn and follow its constructs and don’t get overwhelmed with how the others operate. You can figure that out when the time comes.
