
MVC is dead, it's time to MOVE on (2012) - alxndr
http://cirw.in//blog/time-to-move-on.html
======
jcampbell1
Events are an anti-pattern in my opinion. They allow the ultimate flexibility,
but in essence are worse than global variables. With events, it is very hard
to reason about behavior. Objects respond to messages from "god" at arbitrary
times in an untestable way.

Whenever I am tempted to use an event, I ask myself if there a way to solve
this problem with delegation or data-binding or some other solution.

I fall into the event trap all the time, but when I come across an event-free
solution like Angular/Ember or using delegates in Obj-C, I am immediately
sold.

Any pattern that promotes events as first class ways to communicate are a
recipe for hell. Every Backbone application I have seen is nothing but a messy
event hub that mangles arbitrary DOM events with arbitrary Model events, and
there is a metric shit ton of code that just re-invents data-binding and
delegation.

~~~
dustingetz
Model change listeners are the anti-pattern, not events. Mouse and key events
are essential complexity.

\--

MVVM: model change listeners on each state mutation: response to state
mutation is immediate, never batch multiple listeners, requires dependency
tracking (if the collection changed, then the count also changed). change
listeners fire immediately and can trigger more change listeners. Lots of
callbacks to keep track of and easy for things to get out of whack. (Backbone,
Knockout, Knockback)

Angular ("MV-whatever"): state changes detected by dirty checking, but changes
are immediate (digest loop), never needs dependency tracking. Digest loop runs
until the state settles (no more change listeners fire) to ensure consistent
views. Magic data binding.

Facebook React: state w/ dirty checking: state changes are always batched,
views are a pure function, reconciliation step to merge desired view with
existing view, no events or change listeners. Render process is a lot like a
3D game - draw the buffer, whack the buffer, loop. No magic. Facebook doesn't
call it MVC but in my eyes it is.

\--

The more complex your view and state, the more events/mutations/callbacks, the
more you need React.

~~~
jcampbell1
You seem to know what you are talking about, but I just don't understand what
you are saying. Can you explain the React thing a bit better?

> Mouse and key events are essential complexity.

I disagree, but probably not with what you mean here. Mouse and Key events are
the first thing I want to abstract away, and are an example of the pitfalls of
events. The majority of internet connected devices have neither a mouse nor
keyboard. I don't want to care about key events or mouse movements, but rather
user intent. "submit" and "change" describe user intent; I don't give a shit
about clicks and keydowns, or blitting glyphs into an input box or moving the
cursor on command-a. What does keydown mean when a Chinese person is swiping
chinese characters?

I think of events as chemotherapy. It is one hell of a powerful tool, but
should be avoided for most problems. If every problem looks like cancer, then
your worldview is missing simpler and less powerful but better tools.

~~~
wmeddie
For anyone wondering how Chinese/Japanese/Korean input works interms of DOM
events check out the W3C's working draft of the IME API
[[http://www.w3.org/TR/2013/WD-ime-
api-20130815/](http://www.w3.org/TR/2013/WD-ime-api-20130815/)]. Specifically
the sequence diagram near the end of the page.

~~~
janjongboom
Technically speaking it's the Google proposal, Mozilla is working on a counter
proposal at
[https://wiki.mozilla.org/WebAPI/KeboardIME](https://wiki.mozilla.org/WebAPI/KeboardIME).

------
icebraining
_I 'm certainly not the first person to notice this, but the problem with MVC
as given is that you end up stuffing too much code into your controllers,
because you don't know where else to put it._

No, that's just with the bastardized version of MVC popularized by Rails et
all, which treat the views as little more than templates.

In the original MVC papers from Smalltalk, the views did actually send
messages updating the model:

    
    
       A view is attached to its model (or model part) and gets the data
      necessary for the presentation from the model by asking questions.
      It may also update the model by sending appropriate messages.
      All these questions and messages have to be in the terminology
      of the model, the view will therefore have to know the semantics
      of the attributes of the model it represents.
    

[http://heim.ifi.uio.no/~trygver/1979/mvc-2/1979-12-MVC.pdf](http://heim.ifi.uio.no/~trygver/1979/mvc-2/1979-12-MVC.pdf)

~~~
rubiquity
Rails didn't bastardize MVC, users of Rails bastardized MVC. Over the years
we've seen the progressions of fat controllers to skinny controllers and fat
models. Now, we're seeing the progression of using models only for
responsibilities related to persisting the object. This leads to extracting
additional domain logic into Presenters, Value, Service objects, etc.

Avdi Grimm has a great book about this called Objects on Rails[1] and Bryan
Helmkamp from Code Climate has a good introductory blog post on it as well[2].

Rails implementation of MVC is perfectly fine. It's when people lean on MVC
for everything without applying "classic" Object-Oriented design. That's when
things become a mess.

1 - [http://objectsonrails.com/](http://objectsonrails.com/)

2 - [http://blog.codeclimate.com/blog/2012/10/17/7-ways-to-
decomp...](http://blog.codeclimate.com/blog/2012/10/17/7-ways-to-decompose-
fat-activerecord-models/)

~~~
pyrocat
As an aside on terminology, why do we use the terms "skinny" and "fat"?
Shouldn't it be "short" and "tall" since code is represented vertically?

~~~
steveklabnik
Because that's the title of this blog post:
[http://weblog.jamisbuck.org/2006/10/18/skinny-controller-
fat...](http://weblog.jamisbuck.org/2006/10/18/skinny-controller-fat-model)

The only times 'fat' and 'skinny' are mentioned in the title.

------
Nekorosu
The author's idea of moving events into the name suggests a poor understanding
of OOP in general (with messages/events being the basis of object oriented
approach). Ok, maybe he is talking about some special implementation of events
but there are a lot of GUI oriented MVC interpretations which use some special
events/signals implementation without trying to put it in the name of the
pattern/framework because events are a common part of GUI domain then it
suggest a lack of experience.

Without the E in the MOVE we have just MOV.

Let's talk about Operations now. There are several MVC frameworks which use
different names for the classes related to controllers (for example Commands).
Some implementations let you compose them. They usually live inside
controllers _package_. Do the authors of those implementations rename the C
into somethings else? No!

There are some cases with different names (think MVP, MVVM) but they have a
different form of relationship between the three parts of a pattern. Let's
look at the MOVE's diagram. We actually have the original MVC diagram with a
strange quirk: the controller (made from Operations) can directly affect the
view. Now we have a problem. There are two places in this architecture where
the view gets updated: the view can get events from the model and update
itself (oh horror! it's active view!) or it can be directly updated by the
Operation.

This doesn't solve anything but makes programs built with this architecture
harder to reason about and debug.

There are two ways to fix it: 1\. remove direct changes on view from
controller then we have just MVC 2\. stop sending events from model to view
and send them to controller then we have MVP

In the end I don't see enough justification for calling it something new and
using a special name for this particular pattern. Also this pattern is broken.
Talking about the article itself, it's neither academic, nor pragmatic and
looks like a blatant attempt at self promotion. It's a bullshit which puts
words over meaning and misleads beginning programmers.

------
fleitz
Inner-platform effect in the land of nouns.

Most programming languages already have operations, you don't need to tack
them on as objects, objects generally perform one of these operations when
passed a message.

'events' are generally known as 'messages' and are again built into the
language.

So now we're left with MV, we just need some sort of object that can
send/receive messages from views and models. I think I'll call this object a
controller.

~~~
SupremumLimit
I think you make a good point, but there seems to be more to the OP's events
and operations than you suggest. The 'events' are implied to be broadcast
versus 'messages' which are sent to a particular object (i.e. point-to-point)
in languages that I know.

The OP is also suggesting a hierarchy of 'operations', with sub-operations
communicating with the parent operations. I don't think this maps directly
onto language features (again, in languages I'm aware of).

I'd be interested to hear which languages you had in mind, and some more
detail on how you envisage the mapping to language features.

~~~
fleitz
As for operations communicating this is generally known as a return value.
Parent operations and sub operations is just cleverly disguised procedural
programming.

It sounds like half procedural programming, half partial application.

'Events' sounds alot like [NSArray makeObjectsPerformSelector] / KVO/KVC /
Multicast delegate.

Honestly, the more I think about it the more MOVE sounds like functional
reactive programming.

~~~
SupremumLimit
Thanks, I haven't heard about multicast delegates before, and I need to learn
more about FRP.

------
film42
This is actually remarkably similar to Backbone.MarionetteJS, only, swap the O
with C for Controller (but don't be fooled, even their docs say it's not the
most fitting name).

For those interested in learning more about Marionette, Amy Palamountain made
a fantastic presentation you can check out at her site:
[http://amy.palamounta.in/2013/04/12/unsuck-your-
backbone/](http://amy.palamounta.in/2013/04/12/unsuck-your-backbone/)

------
tn13
I once presented Rails as an example of "MVC" in my software architecture
class the the Prof. kind of ripped me apart saying either Rails it not MVC or
I am misinformed.

After a lot of research I realized that the true MVC architecture is not
something that Rails implement. In MVC the views are updated when models
change without the controller in between. Something like YUI App framework is
true MVC in that sense, but not Rails.

~~~
rubiquity
The original MVC was invented in the context of a fat client which were
desktop-esque applications back in the day. In the context of the Web and HTTP
(which is a stateless protocol) MVC had to be adapted to fit this context.

While your professor was right he's also a moron for being overly pedantic and
ripping you apart.

~~~
dhimes
He thought about it deeply and learned something, though, so +1 for the prof.

~~~
chris_wot
+1 for the _professor_?

~~~
dhimes
Yeah- by 'kind of ripping' tn13 he made tn13 think hard about it. He made tn13
better.

------
vegasje
This is quite amusing, as it was one of the biggest complaints I had when
coming to an RoR shop from a Java shop (please don't immediately take this to
mean that I advocate Java over anything else).

In my Java shop, we used the service pattern. We had our views, our
controllers, our models (which were simply meant to hold data), our services,
and our data access objects. Services performed the business logic, and data
access objects interacted with the database.

This pattern worked extremely well for every application we developed.
Entering the RoR world, I quickly found that most developers forget about all
the lessons we learned back when we used other languages, and are repeating
the quick-and-dirty mistakes we already corrected.

------
dustingetz
_" You have models, which are nice self-contained bits of state, views which
are nice self-contained bits of UI, and controllers which are nice self-
contained bits of...What?"_

Business logic

~~~
mgkimsal
Amen. Except... the current trend I'm seeing/hearing is "nothing in
controllers". There seems to be some hatred of controllers controlling
anything.

~~~
rgbrgb
One of the big ideas for me was that the controller is the least reusable,
most application specific piece. With that in mind, keeping the bulk of the
business logic and view logic in highly testable and reconfigurable models and
views makes a lot of sense. I think of a controller as a mapping between model
and view -- it takes internal state and pipes it to some views then takes
external stimuli and pipes it to some models.

~~~
dustingetz
exactly, and the application specific-ness is what makes them hard or poorly
understood. General DOM management libraries can't provide a controller. For
one thing, it needs to interface with your backend.

------
eurekin
I'm very pleased to see the GUI topic mentioned here. For all of those who
seek a UI advise, I have a tip.

I have done a lot of pondering about GUIs since I began programming. I ended
up in mantaining a 12 year old project, with more than 400 individual forms
(that's for a single client, we've got 4 more). Damn, I was lucky.

The project really blew my mind! It crushed most of the assumptions which I
made while reading articles or developing toy applications.

And here's the thing:

It uses most of the "bad practices", "anti-patterns", or however the internet
calls today the "I was bitten once and didn't find the way out" thing, in it's
codebase and still is ridiculously maintainable. With very much likelyhood it
will survive another 12 years. Partly, because of the contract, but the point
still holds. :)

So, my bold advice: just ignore all the naysayers and make up your own mind.
Event's are bad? It they solve a problem giving another one or two in
exchange, there most probably is another solution fixing those two too. And
while the problems never end, at one time you end up with a framework that
covers 90% of needs, correctly.

"Yeah, we can't notify the remote client about the update on the model, when
it's in a form rollback phase and when it has at least one two-dimensionally
time tracked attribute. It isn't possible, because it interferes with the data
history stack. We should not have used events at the very beginning at all."
Damn, that's a tough problem. Wait, what does your UI do !?

At the project I'm working on it took a lot of work and at least one PhD
thesis to get it where it is today. I can't give out all details, but if
anyone's interested, there are few open sourced parts. But You will find
plenty of good libraries already.

I also made a simple JAVA Swing project on github using some of the gained
knowledge. If anyone would find that interesting, just leave a comment.

I hope such good UI articles come up more often in the HN feed. And please, do
write as much technical details as possible.

~~~
Nekorosu
Is it satire?

~~~
eurekin
No, it wasn't meant to be a satire.

------
jonesetc
Previous discussion from when it was posted(Very active):

[https://news.ycombinator.com/item?id=4189811](https://news.ycombinator.com/item?id=4189811)

------
bdcravens
A problem is that a lot of developers equate MVC with magical framework that
does a lot for me and just happens to have folders named "models", "views",
and "controllers" where they put stuff. This can be Rails, but is common in
other frameworks as well (even if the names change)

I found working with a barebones MVC framework a bit enlightening. One is
Framework One by Sean Corfield. It was originally written in ColdFusion,
consisting of a single class (CF calls them "components") with very little
magic. (it does do things like implicit views and queue up service/model calls
with an event lifecycle, but in general, nothing happens that you don't have
direct control over) He's also written a version for Clojure, though it's less
mature

[https://github.com/framework-one/fw1](https://github.com/framework-one/fw1)
[https://github.com/framework-one/fw1-clj](https://github.com/framework-
one/fw1-clj)

------
tikhonj
If you want a nice alternative to MVC (or event-based systems in general),
take a look at functional reactive programming (FRP). Instead of modelling
time implicitly using mutable state and callbacks, FRP provides time-varying
values as first-class citizens. I've found FRP to create much neater code for
most of the UI tasks I've worked with.

~~~
e12e
Thanks for that, made me finally go and look up FRP, finding this (again, I
think):

[http://elm-lang.org/learn/What-is-FRP.elm](http://elm-lang.org/learn/What-is-
FRP.elm)

It's a nice abstraction when(if) the alternative is to work with the DOM,
javascript and browsers -- but the examples would be trivial in a smalltalk-
like environment: The various labels would reference the mouse, and on redraw
they'd use the current value. So I'm not sure it's so much an alternative to
MVC as it is a fix for our broken environment (the browser+dom+i/o as a GUI
system).

~~~
eurekin
Bookmarked, thank You.

Mind sharing a bit about Your experiences? Are the initial investments cost
high or low? Are there any drawbacks which inhibit any other functionality
(what to do to avoid memory leaks)? Is the end-product really mantainable?
Does compose easily?

I'm eager to learn :)

------
franze
whenever i read a headline like "X is dead" (whereby X is a technological
concept or even a piece of technology) my first reaction is, that the author
has probably a very limited understanding of the technology at hand (or about
the underlying concepts of that technology)

    
    
       * vinyl records are dead, http://www.nytimes.com/2013/06/10/arts/music/vinyl-records-are-making-a-comeback.html?pagewanted=all
       * CDs are dead (yes, they are, optical data storage isn't)
       * flash is dead (but still, most videos are still streamed via flash and a gaming company i know prototypes all games in flash...) 
       * SEO is dead
       * social media is dead
       * java is dead
       * progressive enhancement is dead
       * print is dead
       * native is dead
       * desktop is dead
       * ...
       * ...
       * mvc is dead
    

lets call it "Franz's law of deadliness"

------
sklivvz1971
Talking about an architectural pattern without specifying its applicability or
limitations or context is just completely wrong.

In architecture it's not optional to proceed as follows: 1\. describe a
problem, 2\. describe a solution to the problem

They don't do that. This is a classic mistake: describing a solution and
looking for a problem to solve. Don't do that!

Furthermore, MVC is used because it's widely applicable to a bunch of problems
and contexts - with its pros and cons, clearly. It's actually a very rare
thing for a pattern to have such a large sphere of applicability. So, no, you
don't throw it away just like that. It doesn't make any sense. Sure, there are
other patterns that work better in some very specific context. CQRS is an
excellent pattern for building NoSQL databases for example. That doesn't mean
it should be applied to any random problem!

~~~
AznHisoka
I totally agree.

Also sometimes I feel engineers spend WAY too much time worrying about
architecture of CRUD. I mean, MvC, non-MvC.. who cares? Adopt one and run with
it. Then spend the rest of your time about crucial technical problems(ie
semantic analysis, machine learning, spam detection, whatever)

------
etler
I've been doing something similar to this with Backbone. Backbone has Models,
Views, and Events. I put the "Operations" in the Model and Collection extended
classes, so the login operation is performed by the User model. So I would
call something like currentUser.login(credentials).

------
smoyer
I think there's an easy answer to the question of what the controller is -
it's the business logic. My main problem with the MVC pattern is actually
related to the model and view communicating directly. I started using the MVP
pattern and then switched to passive view
([http://martinfowler.com/eaaDev/PassiveScreen.html](http://martinfowler.com/eaaDev/PassiveScreen.html))
to eliminate as much code (and therefore testing) as possible from the view.

~~~
tieTYT
No that's what the model is for. The controller is just for handling framework
specific input. It takes the framework specific part, puts it in a form that
the business logic can understand (eg: business logic shouldn't even know what
a mouseEvent is), and hands it off to the model's business logic to handle.

------
kapv89
You know what its time for ? To go back bit, beyond the patterns, read "A
Pattern language" by Christopher Alexander. Understand why those patterns
become the way they are, and build software that makes as much sense as real
world buildings. Things that are much more costly than software to tinker
with. Given how much complex shit is becoming today, imposing any fixed label
on how we devs build things would become very restraining very quickly.

------
darylteo
Why is this new in 2012? The "event" component is generally implemented using
the Observer/Listener pattern in Java and has been done like so for yonks. The
most "modern" concept he alludes to in that section is the idea of everything
being modelled as operations (and sub-operations) which is pretty much
Command-Query-Responsibility-Segregation.

This obviously is not convenient in terms of web facing applications. Don't
forget that web pages are intrinsically static which means your model has no
way of pushing events to your view. Unless we (in 2013) are suddenly
advocating that every site now should be using WebSockets (Just as bad as
using PostBacks in ASP WebForms... unless you are writing a client-side
application)? And lets not forget that each web application endpoint
(HTTP_METHOD + URL) is in itself already an intent/operation described here ->
GET = Give Me Information. POST = Mutate Information.

In any case, MVC isn't fully dead as it has evolved into MV(C)VM instead.
Instead of the View getting the data from the Model, the Controller gives the
required information to the View.

~~~
sklivvz1971
Maybe you mean "devolved". MVC is alive and kicking where I sit. Instead I
constantly see the passing corpses of MVVM and CQRS projects... Honestly, not
trolling - this is what I have seen for many years.

~~~
darylteo
Well it depends on how people are using it I guess? ;) just because there are
plenty of MVVM/cqrs projects that have failed doesn't mean that mvc is more
successful... One could propose that devs are more familiar with the steward
of traditional architecture?

Pretty much all iOS projects are MVVM - See UITableView. AngularJS is arguably
MVVM: in this case the views are databound to the view model which is held by
the controller, which is essentially the "Events" component.

Additional Edit: All MVC Java Swing apps could arguably be classified as MVVM
-> all your JComponents are all... MVC! Which really leads me to think that
MVVM is really just nested MVCs... perhaps =)

~~~
sklivvz1971
Well, the problem is that if you find Controllers badly defined in MVC, good
luck in understanding how to use View Models properly. MVVM seems to me on
many levels a re-hash of the old Document/View concept, which is... not so
good, because of coupling. And in fact, Many MVVM codebases end up being
tightly coupled - bear in mind, also many MVC projects, especially of the
ActiveRecord sort.

My comment obviously relates to my experience, which is admittedly more webby
than application-y.

I thought iOS was inherently MVC though (or at least, that's what they claim)

~~~
darylteo
I'd argue that MVVM is a subset of MVC. So technically they're accurate.

And also, anything that is "badly done" becomes bad. I'm not really sure why
it is hard to understand View Models... your controllers shouldn't define your
view models. Your VIEWS determine what information is needed to render itself.
Any templating engine that requires you to pass in a model (i.e. Handlebars,
Jade etc.) is, in effect, MVVM. This makes your views more concise since it
doesn't get access to a whole model when it isn't required. Its dependency is
specifically only on the View Model itself.

------
akrymski
Actually that's what MVC is supposed to be. Whether you use events, callbacks,
delegates, or dirty checking really doesn't matter. Views inform the
controller, controller updates the model. Events and Operations are the
Controller, but lets not shove MVC into some specific implementation based on
events, it's an abstract pattern for software architecture, not a framework.

~~~
asdasf
>Views inform the controller, controller updates the model

No, that's not how it is supposed to work. The idea that everything has to
pass through a controller for no reason, and that we need a controller per
view, is the rails bastardization, not actual MVC.

------
rgbrgb
For those interested in this stuff, Apple has some really nice docs on their
version of MVC:
[https://developer.apple.com/library/ios/documentation/genera...](https://developer.apple.com/library/ios/documentation/general/conceptual/CocoaEncyclopedia/Model-
View-Controller/Model-View-
Controller.html#//apple_ref/doc/uid/TP40010810-CH14)

------
knappador
Have definitely had an excellent experience using an experimental MVC setup in
Kivy. Can't chip into any MVC death exclamations. First I should mention that
Kivy uses data-binding liberally. It's not events, it's publisher-subscriber
where bound functions receive the changes as their arguments. This fixes many
things, but Kivy uses a widget tree. Trees are great for reasoning about
context, scope, relationship etc between graphics elements in layouts.

Trees are also an awful topology when something has a relationship to an
element in another branch. The controllers as I'm using them are globally
visible and thus don't need to be passed. This would pollute namespaces except
that a minimal number of controllers will recreate the topology of the problem
space and not in tree-space. The whole application can see "out" of the 2D
tree into a graph that connects things with many fewer connections. These few
controllers have tons of logic, but it's all program. There's very little
related to how widgets display themselves, so this fat code is also very high-
calorie, rich or whatever.

Fat controllers make me happy. My program, the part that I think of as the
program, exists all in one place and the bits that control how everything
looks all belong in the tree. Widgets don't send events to my controllers
often. Occasionally it's easier to reason through a problem using the
property/data-binding system, but more often the data already exists in the
on_press callback of the widget or whatever and there's no need to secondarily
send it through more sub/pub plumbing when I can just call a function of my
global controller on the data.

I'm busy getting my code cleaned up and contributed. It has really saved me
untold time even in it's nascent stages because of the fundamental topology
conveniences.

------
jtreminio
I was never a fan of "strict" web MVC. It felt like you were jamming far too
much into your models.

Take Symfony2's architecture, for example. Controllers, Entities,
Repositories, Views, Services, Listeners, Events, etc. Each layer has its own
distinct purpose that do something very specific by themselves, but when
brought together form a very cohesive whole.

~~~
dscrd
>Take Symfony2's architecture, for example. Controllers, Entities,
Repositories, Views, Services, Listeners, Events, etc. Each layer has its own
distinct purpose that do something very specific by themselves, but when
brought together form a very cohesive whole.

But the end result is so very complex and the benefits gained are doubtful at
best.

~~~
camus
You obviously never worked with javaEE ... Symfony is a breeze compared to how
the former works.

------
spenczar5
Should be mentioned that this is from 2012.

------
joeheyming
I like to think that its not model view controller, but instead model-view-
behavior (or the strategy pattern)

Events are a given. Models can fire/handle events, views can fire/handle
events. The behavior/strategy pattern is just a bunch of singleton objects
that know how to mediate between the view and the model. Sometimes the
behavior pattern handles events (as a strategy), but it doesn't fire events
(only the model and view can do that).

The model knows how to generate the behavior. The View contains the behavior
and asks the behavior questions with the model.

This separates responsibilities nicely in my opinion.

------
ttty
"A common operation for applications is logging a user in. It's actually two
sub-operations composed together: first get the email address and password
from the user, second load the "user" model from the database and check
whether the password matches."

Why do you need to have Operations when that code could be into the model? The
view tells the model: login(username, password); and the model just do that
and saves the state in it's model.

So there will be models that contains state and models that contains data...

Why add another layer?

------
tantaman
looking at the comments, few programmers even understand MVC yet. Maybe it's
just a lack of understanding that causes people to think it's time to MOVE
on...

------
mason240
>O: Operations encapsulate everything that your application does. >E: Events
are used to join all these components together safely.

So my controllers are just there to work with the repository/service layers.
This is just the next logical step after straight MVC and is already a pretty
well established pattern.

 _My understanding of MVC is the context of web development._

------
dep_b
Sounds like my reaction on Apple's version MVC: "Do I have to stuff ALL of
this stuff into a Controller???". But if I use something like LESS with a ORM
or Microsoft MVC with EF and nice IOC and builder patterns all of a sudden the
controller does nothing else but evaluating the request and giving the right
kind of response.

~~~
Aqueous
Indeed. Even if you are not using an ORM, controller functions should be
short. Functions are just not supposed to be 30+ lines.

If my controller function isn't less than 20 lines of code I look over it and
figure out what code can be placed in a library or a model or a view. The
controller function should do very little.

------
ph4
Can someone provide a basic introduction to the concept of MVC, for a
beginner?

~~~
MereInterest
Basically, you have your program in three parts. Model, view, and controller.
The model is the meat of everything. It knows the system, it interacts with
other programs, it determines everything. The view is what gets shown to the
user. The controller is what the user interacts with. Both the view and the
controller should be as minimal as possible, only serving to relay information
between the model and the user.

~~~
e12e
And one place that is easy to trip up, is that you'll probably want to model
your data, eg do normalization. That is your applications data model. But that
is _not the same_ as the model in MVC.

The "MVC-model" of a bank account is an account number with a balance
attached: the _data model_ of an account is a series of credit/debit
transactions that can be summed up to a current balance.

------
methodin
Blindly picking a design pattern before you develop your application will
always be bad. Don't do it. If you do be prepared for tired legs because the
chase to find a better one will be never-ending.

------
zamalek
Sounds very similar to CQRS, but from a UI perspective. Interesting.

I wonder how this applies to stateless systems (HTTP) though. It seems like
it's really geared toward thick client applications.

------
ffrryuu
AngularJS is the future.

~~~
solox3
We built a prototype app using AngularJS. For our specific usage of AngularJS,
while we achieved our goal with the least LOC, its performance is so poor [on
mobile] compared to Ember.js, CanJS and MarionetteJS that it was certain that
AngularJS is indeed designed for the future, but not the present.

~~~
SkyMarshal
If you did any kind of systematic comparison of those, write a blog post and
post it here. I bet it would get a lot of discussion. Angular's mobile
performance is very interesting, but not something that seems to have gotten
much attention yet.

------
peterhunt
I think the key takeaway is that your view is read-only. An abstraction that's
great for reading isn't necessarily great for writing.

------
creatrixcordis
Who cares what you call it? As long as it does what i need. Models, Workers,
Controllers, Views, Events, Masks, Filters, Actions...

------
Leander_B
Not talking about the content of the article, but this 2-column style of
reading is not very pleasant for the web.

------
hessenwolf
Sshhh... I have just moved us on to this in the office.

~~~
Guvante
I dunno, this and most the other complaints about MVC are about the ambiguity
of the controller definition, not the fundamental concept.

------
hawleyal
MVC is dead, long live MVC.

~~~
rhengles
The reports of the death of MVC are greatly exaggerated.

------
volokoumphetico
can we see a node.js framework with MOVE principles?

