Hacker News Reader

Comment by specialist | Hacker News Reader

There is no MVC.

A design pattern is a reusable solution to problem, given a certain context (set of constraints).

My design pattern study group iterated over the Gang of Four book 3 times, please many others. The MVC sessions were the least constructive.

No two people could agree on what is and isn't MVC.

Or MVP. No, you're not doing it right. Oh, MVC can only be done "correctly" using Smalltalk.

Yadda yadda yadda.

I can't even begin to discuss "MVC web frameworks". Huh? Methinks the only reason for "MVC" is to justify Spring, inversion of control, containers, dependency injection, annotations, and all that other useless enterprisey J2EE-esque shovelware.

I agree with jerf's statement (upthread) that devs should worry more about DRY than MVC.

View on HN

There is MVC. Its just a concept, unlike those design patterns from GoF which are specific.

Models are just data, View are just representations and Controllers are just endpoints. You can program your own way in your language, and if you can categorize your code as such, you can argue it is MVC.

And of course, because its just a concept, anyone in the world can argue why your implementation is not MVC as well.

No, MVC is not the reason to justify Spring, inversion of control, containers, dependency injection, annotation and all other "enterprisey J2EE-esque shovelware" as you mentioned.

MVC has been around since SmallTalk (you know, before even Java...). Heck, you even get MVC in Rails. You see Spring in Rails? Dependency Injections? Annotations? Of course not, since I could not even begin to think they are related.

Of course not, since I could not even begin to think [Rails and Spring] are related.

Sure they are.

Spring is the Java community's effort to get some of that dynamic programming goodness (ahem).

Rails is the Ruby community's effort to reproduce the unmaintainable mess of J2EE.

You couldn't have one without the other.

You are right, MVC means different things to different people, so whenever someone says "MVC" I try to stop them right there and ask to explain what exactly they mean before proceeding any further.

Martin Fowler has an excellent write up on the history of MVC and related patterns (and resulting confusion) in http://martinfowler.com/eaaDev/uiArchs.html.

I'm very aware of Fowler's write ups. That one is a pretty good summary. In that it's descriptive, but IMHO is completely unactionable (prescriptive).

I've written a direct manipulation vector structured graphics program. Think FreeHand / Illustrator with a scenegraph. I tried every which way to make something MVC esque. No can do.

I believe, but cannot prove, that the MVC failing(s), eg tight coupling, unclear flow of control, comes from the Observer/Listener like message passing between the players.

Further, I believe some future UI paradigm will be a hybrid, mutant love child, inspired by, of functional reactive programming and an VRML-97 like event model (FROM->TO style patchcord event routing). It's on my to do list, but I'm easily distracted and followed thru.

Reply on news.ycombinator.com