Hacker News Reader

Comment by tree_of_item | Hacker News Reader

Does anyone else not really get "MVC"? It seems like every person has their own idea of what it is and no two frameworks can agree on what the necessary parts are. I get the feeling MVC is mostly a bunch of handwaving about separation of concerns, motherhood, and apple pie.

View on HN

Me. I really struggled with it early on when I was moving from single file php to frameworks, so I read head first design patterns. There MVC made sense; you had state to maintain, and changes to make; MVC still holds up well in desktop GUI applications. But on the web you throw away the world on every request, so essentially you're just running a big API where every request gets interpreted by the controller, acted on by the model and rerendered by the view; basic separation of concerns. All of these "model pushes changes to the view, controller accepts actions" stuff from the original MVC seems like it's really poorly mapped to the web. I still don't know if it just hasn't clicked yet or I'm doing it all wrong or something, but I really wish I could have a bit more certainty when I'm architecting new projects that I'm doing MVC "right".

The original MVC architecture was for GUI interfaces in Smalltalk. It was so helpful a design pattern it was borrowed for use in request/response web application, where naturally the use of each part was very different.

If you really want to "get" the original MVC, see the classic book "Smalltalk, Objects, and Design" [1] which explains MVC and other OO architectures as well as the principles behind them, which might guide you to picking an appropriate structure for applications that don't fit the GUI/MVC paradigm.

[1] http://www.amazon.com/Smalltalk-Objects-Design-Chamond-Liu/d...

My original implementation of Mvc was writing a game of connect 4 in java. There was a board model. There were two views. One graphical, and one command line. You could update both views by clicking your next move on the graphical board, or putting input on the command line. Once the model was updated, the controller would update any view that was listening on it.

The controller shouldn't be updating the views. The views should be observers of the models. The controller updates the model, which triggers messages from the models to their observers, the views. They would then would then reflect the change in the model.

I sort of evolved my own PHP framework pattern after I did my first few webdev jobs and identified the problem areas. This was before I had ever used a MVC framework.

Looking back at it now, it had everything your typical web MVC framework has, just slightly diffrent:

* Models, with cleanly encapsulated functionality, but without an ORM. I only built small websites, so all related database tables were managed by the same model.

* Controllers that handled all input and delegate it to models.

* Views in the form of HTML code following the controller code in the same file, but strictly separated.

* "Forms" that abstracted away the controller/view and input validation of forms in a neat, reusable package.

My point is that whatever you come up with that actually works well and lets you be productive will more-or-less resemble MVC.

For a succinct description that also explains the origins of some of the discrepancies:

http://c2.com/cgi/wiki?ModelViewController

MVC is just a design pattern, a way to organize code, it's not a religion.

I wouldn't like it to be a religion! I'd just like some precision. Design patterns point to a large region of possible configurations, so to say something is "MVC" isn't saying very much.

Reply on news.ycombinator.com