
MVC is dead, it's time to MOVE on - cirwin
http://cirw.in/blog/time-to-move-on
======
scrame
This sure looks like MVC, but they call the Controller "operations".

The MVC abstraction has an issue with web applications, since the request-
response cycle doesn't provide feedback as directly as the hardware-monitor-
software cycle that the pattern was originally designed around.

However, if the problem is that you are putting too much "logic" into your
controllers, you should probably find a better place for it.

In Java/Spring-MVC, there is a typical class hierarchy of Controller ->
Manager/Service -> DAO. The extra level of indirection is a very handy place
to put business logic, then each class in the tier has a dedicated function:

    
    
      Controller -- Parses input, delegates the action and returns the response (rendered by the view).
      Manager -- Handles sanitized data, encapsulates business logic and makes calls into the Model / Data layer.
      DAO -- Interfaces with the data store, makes sure only good data goes in, and appropriate responses are returned.
    

This approach doesn't seem to offer anything more than that, except for
putting a label on the messaging between subsystems, but those operations are
not well defined (at least in this piece), and seem like another nebulous way
to bury logic.

It seems like this problem has arisen from a rather narrow reading of what an
MVC system should be, as in, not having utility libraries because they aren't
strictly an M a V or a C.

*edit: formatting.

~~~
cirwin
It's very similar you're correct, particularly when you add in the
Manager/Service layer (something that I hadn't spent enough time
investigating).

The main advantage of Operations over controllers is that they're fully
composable. You can take the operation that logs a user in (which displays the
login screen, and awaits the user typing a username and password) and use it
as a sub-part of any other operation.

In a purer MVC world you get something similar to this by making a function
that instantiates the login controller with its associated view; that's pretty
good, but there's no obvious place to put that function.

I'll certainly be following up with more details, and some actual code.

~~~
eaurouge
This thing you're calling MOVE, how is it different from Qt's MVC + signals
and slots [1]? You've discovered a new (for you) way of applying MVC and
you've gone ahead and given it a new name. Nothing in your blog post is new,
except the name of course.

If I sound snarky, it's because I'm sick and tired of similar opinionated
proclamations in too many self-important blog posts.

Edit: Re the down votes. If you're going to write posts with titles like "MVC
is dead" with no justification whatsoever, then proceed to self-post on
HackerNews, then I feel justified calling you out on it. Again, I would
appreciate someone informing on how MOVE is fundamentally different from MVC.

1\. [http://doc.qt.nokia.com/4.7-snapshot/model-view-
programming....](http://doc.qt.nokia.com/4.7-snapshot/model-view-
programming.html)

------
nicholassmith
You know it's nice reading a criticism of something that has an alternative
solution offered rather than just going "hey MVC is terrible and you're an
idiot for using it".

I do however think there's still great benefits to MVC, if you're shovelling
code into controllers and can't make it work like it should then MVC is not
the right design pattern for the project. Like every other pattern it'll only
work when it works, but MOVE sounds like an interesting addition that I might
have a play with.

~~~
jerf
MVC is terrible _for web apps_ (in the original local GUI domain it's fine for
some things), you aren't an idiot for using it because you're probably not
actually using it but rather only something loosely inspired by it, and the
solution is simply DRY. MVC at its best is simply one manifestation of DRY,
but there's no real reason to get too stuck on it when with practice DRY is
something you should just always be doing. If MVC falls out of that, great,
but if not, so what?

(The original MVC is actually useless for web apps because there is no client-
server connection in it, and that profoundly changes everything. There's no
point in trying to bash a GUI top-level design into a new client-server world,
especially when DRY is just sitting there, waiting for you to use it.)

MVC, MOVE, all the variants just obscure your vision from the underlying and
far more important principle.

~~~
Xurinos
I suspect this is because most people do not actually understand what MVC is
and how it applies to server-client relationships; in fact, the wikipedia
article on MVC is slightly off on the subject, assuming one accepts the
original Xerox description as a source. Try not to wrap the entire complicated
application into one big MVC umbrella because that will just confuse. There
are actually multiple processes involved, and each has its own MVC.

The big epiphany for me was when I realized that the server has its own MVC,
and the browser has its own MVC. The server's output is the View for the
server and the Model for the browser. For a complex set of objects in a given
Model, the final output of those objects is their View, and the consumer of
that output uses it as a Model. In theory, any View can be a Model for the
thing accepting the View, so in a complex system, you have a chain of MVCs.

And one can further imagine that applets written in JavaScript have their own
MVC unit.

I work on complicated, large-data web apps sometimes daily. MVC has been a
fine model for them and has kept my group's organization clean and modular.

~~~
saraid216
> in fact, the wikipedia article on MVC is slightly off on the subject,
> assuming one accepts the original Xerox description as a source.

People complaining about factual inaccuracies on Wikipedia annoy me. It's
Wikipedia. The entire point and purpose of it is to fix what you know is
wrong.

For once, I'd like to see, "I just touched up the Wikipedia article on this
subject to explain it a bit more accurately."

~~~
mortenjorck
>"I just touched up the Wikipedia article on this subject to explain it a bit
more accurately."

"But then all my changes were reverted by an overprotective editor; I brought
the issues up on the talk page, but my comments were brusquely dismissed."

~~~
saraid216
Your changes would still be in the edit log, and someone more savvy in
Wikipedia politics would have the opportunity to get your changes cemented.
Said person might be another HN reader who is less knowledgeable about the
subject matter.

If you don't make any changes, he has nothing to work with except some random
whining.

(And yes, that's how it works in the real world, too.)

~~~
jaylevitt
Are you volunteering to help push through wahnfrieden's REST changes, then?

~~~
saraid216
His comment does not imply they did not go through.

------
jaaron
MVC, more than other design patterns, is horribly abused. Developers should
keep in mind its GUI roots. Here's my "is it MVC?" litmus test:

How much of my code survives if I drastically change the view?

For example, if I want to switch to a new desktop, web or text console
interface, can I reuse much of the application? Of course, architecture
changes this significantly (particularly web architecture), but still, if I
cannot swap out the view, then I'm losing out on one of the significant
advantages of an MVC architecture. One way to make sure this works is to start
with 2 views from the beginning - the view you're actually going to ship, and
a headless view for tests.

~~~
jshen
my rails apps pass this test with flying colors. Nearly all of my end points
have at least 3 views. 1 for html, 1 for json (often used for ajax calls), and
1 for rss/atom.

~~~
blahbap
JSON and RSS views don't make sense - in MVC, views are visual representations
of data (the model). Views are how the user percieves the application. JSON
and RSS are just different methods for representing data to be communicated to
other systems.

~~~
corford
Not saying I disagree with you but then where exactly would the JSON and RSS
output methods go in an MVC framework, if not in a view i.e. how would a
different system or user consume/access their output? Directly from a
controller? Would love to know your thoughts as I've always found MVC a
difficult conceptual approach to grok when applying it to web apps (lots of
code never seems to have an obvious M, V or C home).

~~~
blahbap
Services that provide data as JSON and RSS are not part of MVC at all. Even if
you use MVC for your application, not _every_ part of your application has to
fit into MVC. You use MVC only for the part of your application that
communicates with the user. Other parts of your application, like external
APIs, should not be crammed into any of your MVC components. A service that
provides RSS or JSON on request would simply fetch data in a database and send
it along, bypassing all your models, views and controller entirely. (Note that
the database is not considered a part of MVC).

------
guelo
The best practices I've seen for MVC apps isn't to put all the logic in the
controllers. What you do is to create a "services" or "managers" layer that is
called on by the controllers. A userService, for example, might have a
function

    
    
      user = userService.login(name, password)
    

It's also nice to abstract this service layer with some clean interfaces so
that you can replace the underlying implementation, for example to move from
MySQL to Memcached.

Using events for everything has appeal but my experience is that the added
synchronicity problems creates unneeded complexity and makes reasoning through
the logic and debugging hard.

~~~
juliano_q
I agree, I really like the "services" layer. I used it for years programming
with Java/Spring and missed a lot when learning RoR. I think it is no
coincidence that the two RoR real-world projects that I worked had enormous
controllers. The service layer is great to orchestrate operations between
models and I don´t know a reason for not using it.

~~~
Daniel_Newby
Does anything stop you from using a service layer with Rails?

~~~
juliano_q
No, but it doesn't seem to be a common practice. Actually on my personal
projects the first thing I do is to create a service layer, but sadly the real
world projects that I jumped into never had it.

------
Androsynth
Are you talking about pure mvc's like sproutcore? faux mvc's like backbone?
model2 patterns like rails and most other server side architectures? I think
what you mean is 'Model2 is dead...'. MVC is great for any environment where
the observer pattern can be implemented (eg web front-end).

The biggest problems I've seen in model 2 architectures is weak models. The
side effect of this is everything gets stuffed in the controllers. This is
understandable because there is no observer pattern and therefore the models
don't have nearly the power they do in real MVC.

Heres a great explanation of the MVC[1]:

 _In a nutshell the classic MVC architecture work like this. There is a model
that is at the heart of the whole thing. If the model changes, it notifies its
observers that a change occurred. The view is the stuff you can see and the
view observes the model. When the view is notified that the model has changed,
the view changes its appearance. The user can interact with the view (e.g.
clicking stuff) but the view doesn’t know what to do. So the view tells the
controller what the user did and assumes the controller knows what to do. The
controller appropriately changes the model. And around and around it goes._

[1] [http://michaux.ca/articles/mvc-architecture-for-
javascript-a...](http://michaux.ca/articles/mvc-architecture-for-javascript-
applications)

~~~
kenster07
In practical terms, those observers would have to live in the controller, or
there would be coupling between the model and views.

~~~
Androsynth
The observer is supposed to be baked into the framework itself. Theoretically,
setting a value on your model will update the view without you having to write
any code.

------
alttab
This is certainly interesting. I like the event based model. Here are my
thoughts:

If your controllers are getting fat and spaghetti like, I wouldn't blame MVC.
There are many patterns one can use that are compatible with MVC without going
to a completely different architecture. For instance, if you need to
encapsulate multi-model interaction you can create a presenter abstraction
that the controller simply calls into. Just because there is a bunch of code
that ends up in the controller because "you don't know where to put it"
doesn't mean there isn't a better place to put it without re-designing the
entire application.

Another thing is while I love the data-binding event deal, this really only
works for client-side frameworks like Backbone. Server-side kinda goes at the
window, but I suppose you could add a framework that piped event signals in
the response from changes that occurred in the ORM layer (although this
further couples components).

I'm not convinced that separating the data from the methods that operate is a
great idea unless you want to go purely functional. Doing this clearly breaks
encapsulation, throws any notion of OOP out the window, and still binds the
"operations" too closely to the data. Generally speaking, the data is useless
without the operations and vice versa.

So the real difference between MOVE and MVC, at least according to this
article, is that models are no longer useful on their own, the controllers aka
"operations" know everything about how to manipulate models (it shouldn't),
and models generate events which are only consumed by views, which makes no
sense if you wanted to use the model on its own (but you can't without your
operations).

Generally speaking, the model should _MODEL_ something. That includes data and
behavior. Without both, you have a database, and a set of operations kinda
like a C library but only because OOP hadn't been invented yet.

In my mind this further couples all of the components because it actually
increases the reliance on each other for them to be useful.

MVC isn't dead. There is a good chance you are using it wrong. I highly
suggest Rails Antipatterns. While it is specific to Rails, it works for MVC in
general. [http://www.amazon.com/Rails-AntiPatterns-Refactoring-
Addison...](http://www.amazon.com/Rails-AntiPatterns-Refactoring-Addison-
Wesley-Professional/dp/0321604814)

edit: spelling

~~~
pestaa
Sorry, but data-bound events are not useless in server context. It might be
exactly what we need when fat controllers go out of control. Perhaps you meant
they are too much of a complication if taken too far to work across all
concurrent requests?

Binding data and behavior together breaks the rule of single responsibility,
which I believe is far worse than designing separate roles in sepearate
components that work together. Models should _model_ the data structure only,
if you need a presentation abstraction anyway for multi-model operations. Why
not go the extra mile and use this abstraction level for all operations?

It is a false dichotomy that you go either full-OOP or purely functionaly.
Models _wrap knowledge_ as the article suggests, _That means that, in addition
to getters and setters, they might contain functions that let you check "is
this the user's password?"_. I envision these methods to work on a single
attribute, whereas multi-attribute and multi-model business logic belongs to
operations.

MVC isn't dead, but it was a local maximum OOP gave us. Event-driven
development seems to raise and work well with objects and datasets.

~~~
alttab
If "fat controllers go out of control" then you've already made multiple
mistakes. I don't think re-inventing the wheel is the right approach to fixing
a problem when the developer can understand their own mistakes instead of
blaming a framework or architecture.

Are you suggesting that OOP breaks the rule of single responsibility? Any
'operation' that modifies the internal data should belong on the model. Would
turnLeft() belong on a Car model? Or do you pass a Car into a turnLeft
operation? In my mind a turnLeft operation shouldn't know the details of how
to turn a car left, or a bike left, or a boat left. These operations belong in
the Car, Bike, and Boat.

~~~
drone
Somewhat pedantic, but just throwing this out there: cars, bikes, and boats
are all forms of transportation which can turn. They should probably inherit
the concept of turning left, and then specify the exact meaning in their
context.

Obviously, I don't say "turn your handlebars such that the left side is closer
to your chest," or "rotate your steering wheel counter-clockwise," when I mean
to tell someone to turn left at the next intersection. I might, however, tell
a sailor to steer to port at the next buoy. =)

EDIT: forgot to say, fwiw, that I agree that such actions do not belong in the
model. The things go in the model, and the only actions the model should
support are those relative managing the data in the model, not interacting
with the data... That is, after all, what the controller is for.

~~~
einhverfr
I dunno about the last part.

I think any logic inherently tied to the data should be in the model. The
controller shouldn't have to worry about internals of the model any more than
necessary.

Here's an example. Suppose I create an i18n framework for handling numbers. I
certainly am going to include in it a function for converting the number into
the current user's localized format, and another one for converting the number
from the current user's localized format. I will probably also have functions
to convert to/from db formats and to/from arbitrary formats. Not all of these
will be called by the controller (in most cases, just the ones to/from the
user's localized format and _maybe_ an arbitrary format on rare occasions).

This way the controller script can just call something like
$number->to_output; and get the localized string back. Other model objects can
call $number->to_db and get a string suitable for entry into the db.

Interestingly in LedgerSMB 1.4 where we have done this, the number of cases
where the model calls number i18n functions are remarkably small. These are
usually called in the model or in the view simply because the controller
probably shouldn't have to worry about this, and the view gets to worry about
display logic.

~~~
drone
Converting the display format of data when requested by a view is exactly what
a model is supposed to do.

However, instructing a contained object to take some action at the user's
request that is unrelated to display or management of contained objects is
neither the responsibility of the view or the model, but specifically the task
of the controller.

~~~
einhverfr
Ok, so let's go further.

I want an email to be sent to me when the quantity on hand of a part gets
below the re-order point.

So now, I build a program that listens for notifications, and when it gets
one, loads the data, erases the queue, and sends me an email.

I build this so the app itself doesn't know this is required or is going on.
Database triggers, queue tables listening scripts, and templates all are
triggered when the db write takes place.

Now, what we have here are arguably two MVC environments where the model
behavior of one triggers a model change in another, which triggers a
controller to run, calls some other model stuff, creates an email (via a view)
and sends it.

But this is the sort of action you are talking about, right? You think this
violates separation of concerns?

~~~
drone
This is very unclear - the database is not the model in the app, it's the
storage for the model. (In its own application though, it may be a model...)
You've abstracted some application functionality into the data storage, ok.

I'm speaking to the point that if you are separating Model, View, and
Controller, and you have complex objects in your model that can do many
things, it would not make sense to put all of the logic about what those
things can do, how to do them, and when to do them in the model. Otherwise,
you're simply blending the model and the controller (which may not be a wrong
thing to do) - so you just have MV.

Let me give a more concrete example: I have a model which represents a network
of connected complex "devices," there are five types of devices, each that can
do 50 distinct things. The model can add a new device, delete a device, or
retrieve an existing device. It can also ask the devices what their names, and
addresses are, and what features they support, on behalf of any view which
needs that information.

It cannot, however, tell device 1, which is of type X to take action "foo".
That, instead, is implemented by a controller attached to a view that shows a
big button that says "Do Foo", and a drop-down with the list of available
devices that can do Foo. The view passes the press of the button onto the
controller, which asks the model for the selected device, and then executes a
"do Foo" command on it, and then, perhaps, contacts the device again to check
that "Foo" was completed.

If all such logic were built into the model, I'd have several hundred methods
in it, and I'd be very quickly looking for somewhere to move all of this
logic, like, you know, controllers.

~~~
einhverfr
The database is not the model but the db operations are usually _in_ the
model, right?

My point though is in essentially shimming functionality. In my example, for
example, here is how it would work.

1) User requests "save this invoice", which activates a controller script
which automates the model elements for "invoice" instantiates an invoice
(since this is a stateless web app) and saves it.

2) The model saves the invoice by writing it to the db.

3) Saving to the db fires a trigger which checks ROP vs on-hand and where ROP
is greater saves a record in a queue table and issues an asynchronous
notification, which doesn't have any immediate effect.

4) Controller commits the db transaction. The DB sends out the notification
and makes the rows in the queue table visible.

5) Controller for application b wakes up (let's say every 15 min) and polls
for notifications. Ok, we got one. Look up the queue table, prepare the email
(model stuff) runt he template (view stuff) and sent it out (model stuff
again).

So what I am getting at here is a way to have model events have side effects
which are outside the scope of Application A, but are at least triggered by
model operations. This is not an anti-pattern really because application A is
not relying on those side-effects for operation. However if you look at
application A as the primary one and application B as contained within it,
then application B can only be described as contained within the model of
application A, from application A's perspective, because all of its
functionality is abstracted behind the model. From application B's
perspective, there is a model, a view, and a controller, and it doesn't care
as to where notifications and queue table data is coming from. From it's
perspective it is a loosely coupled app in its own right.

But as always what I am suggesting is that common sense usually determines the
best place for a given piece of logic. LedgerSMB is very model-centric but
there are cases where we have a fair bit of logic in the controller.* I think
that anything which is inherent in the model belongs in the model. So back to
the vehicle analogy, a bike object should support a $bike->turn('l') and a
$bike->turn('r'). However telling the bike when to turn left is the
controller's job.

* for example in contact and employee management, the controller has to coordinate a lot of different model operations, leading to unusually long/complex model code in the system.

------
moe
It's amusing how the agile crowd slowly goes through the same learning curve
that the java-guys rode 10 years ago.

That's a good thing, though. They're at the verge of rediscovering SOA now and
there's hope this incarnation will be less plagued by IOC-fluff and
boilerplate, simply because the involved people have more of a hacking and
less of an engineering background.

I, for one, am looking forward to the "great shattering of Rails".

~~~
krsunny
How is SOA like teenage sex?

Everyone thinks everyone else is doing it, few are actually doing it and the
ones that ARE doing it are doing it wrong.

------
martian
This pattern is fantastic.

We use a similar pattern that we internally call "Actions". An Action, in our
parlance, is similar to the Command pattern from the Gang of Four. It can be
invoked from anywhere and performs a single state change on a single model, or
even multiple models (if several need to be updated at the same time, in the
same transaction).

Separating Actions from Models was a huge step in writing readable code, and
it's immediately clear what is happening in the system at any given time. Any
Action can invoke any number of "child" actions, as well, to maintain
encapsulation. For example: when a user registers on the site, we trigger a
RegisterUser action, which in turn calls a CreateUser action and a LoginUser
action.

Basically, we took any complicated method on our models and turned them into
Action classes. Common concepts like database transactions, logging, event
tracking, and so forth, can now be abstracted away, and don't need to be re-
implemented in each model class. It's a huge productivity increase and a real
win for software engineering.

I highly recommend this general approach to any large software system, and I'm
grateful that we're all experimenting with things beyond MVC.

------
drostie
If your controller has too much logic you should really consider putting more
of it in your model and view.

Maybe I don't understand MVC, and you all can tell me How Wrong I Am, but
here's how I understand MVC at present:

Your Model is a public API, a Service Gateway -- and it should do a couple of
things in principle. The first is that it should be able to manage a list of
subscribed view/controllers, and push updates out to them -- this was
difficult with Web 2.0 but we're now moving to systems where this is
considered normal. The second is that it should define a set of API commands
which change that state and push out those subscriptions. That second bit is
crucial, it's the difference between writing assembly and Python. If you have
logic in your controller then it's probably because your model does not expose
certain high-level concepts which your controller would use directly, so
you're taking data from the model and building a higher-order model in your
controller, before you operate on it.

It helps me to remember that in Smalltalk the idea was to always have
<view|controller> pairs. They were always the same object split in two; each
view had its own controller and vice versa. The controller is supposed to be
input-oriented and the view is supposed to be output-oriented; the model says
"hey, X changed" and the view updates what X looks like; the user clicks on X
and the controller sends a signal to the view to change some more, the user
erases X and the controller sends this request to the model, which will update
the view when the request is complete.

Viewed this way it's really hard to see what the difference is supposed to be
between MVC and MOVE. Clearly the messages in MVC are the Events in MOVE. Most
of the controller logic has been pushed into the View, which should now handle
input actions. Data cannot be dynamically pushed from the Model to the View
because this is of course a Web 2.0 technology (pre-cometcasting, pre-
websockets). The Operation sits in a grey area, implementing higher-order
abstractions from the lower-order model.

Maybe we could do better with a hybrid, because the idea of decoupling
subscriptions from the public API might actually be a good idea, in line with
the Clojure philosophy that things should be de-complected into their simplest
representations. But if I understand MVC right, then I don't see why you've
got all your business logic in your controller. Heck, the View is supposed to
be client-side, why isn't your Controller client side? Or if it is, and you
have all this business logic in it, why are you trusting the client to do your
business logic? Your gripes with MVC don't make sense to me.

~~~
stonemetal
Sounds about right to me. Model in MVC isn't data model, it is a model of the
application domain, aka business logic. The controller is supposed to map low
level input to high level model actions. The view goes the other way, high
level model representation to low level operator display.

~~~
jrgnsd
I think for a lot of people the Model is the DB layer. They then (rightfully)
realize that you shouldn't combine business and DB logic, and then move their
business logic into the Controller.

So they're fixing a valid issue with an invalid solution, causing bloated and
dual purpose (business and application logic) Controllers.

------
kenperkins
I prefer the term "Services" over "Operations".

Services is where the logic of your application should live, and services
should be HTTP (or any protocol) agnostic. They should only speak in models
and native types, and should abstract all of your logic away from your
controllers and models.

This leaves the controllers as a thin http handling layer that parses inputs
and then lets the service handle the work.

The response from the service is then transformed appropriately (JSON, HTML,
etc) and sent back to the caller.

Just my $0.02

~~~
Yhippa
"MSVE" just doesn't have the same ring to it :-)

------
Alexandervn
Addy Osmani has a nice excercition [1] on the history of MVC in Developing
Backbone.js Applications, where he states:

"Developers are sometimes surprised when they learn that the Observer pattern
(nowadays commonly implemented as a Publish/Subscribe system) was included as
a part of MVC's architecture decades ago. In Smalltalk-80's MVC, the View and
Controller both observe the Model: anytime the Model changes, the Views
react."

So, not really new actually.

[1]: <http://addyosmani.github.com/backbone-fundamentals/#mvc>

------
Erwin
An interesting new pattern here (from the creator of MVC) is DCI:
<http://en.wikipedia.org/wiki/Data,_Context,_and_Interaction>

Essentially it's a way to move code where multiple objects collaborate to
achieve something into its own separate class (Context). However when
executing in a context, each involved object takes on a "Role" which grants
its additional methods specific to this context.

~~~
mempko
Thank you sir. I was worried nobody would mention DCI. I believe DCI is a far
better solution to the MVC problem of dealing with 'algorithms' than MOVE.
MOVE almost seems to be MVC plus goto.

------
zacharyvoase
> I don't wish to be misunderstood as implying that MVC is bad […] Since it
> was invented however, new programming techniques have become popular.

This doesn't make any sense to me.

The first problem is the blatant _argumentum ad populum_ —just because other
things are popular _right now_ doesn't mean they're better.

The second problem is: I simply do not agree that we have new technologies
that are so radically different and empowering from those that were available
when MVC was invented. Indeed, Smalltalk (the language in which MVC was
conceived) has late binding, dynamic typing and code blocks. I still think
‘modern’ scripting languages are playing catch-up with Smalltalk and LISP in
terms of power, performance and clarity of expression.

Trygve Reenskaug (the inventor of MVC) later went on to develop DCI, a system
which complements MVC, rather than replacing it wholesale. I'd recommend
reading the Wikipedia page for more info, it's a coherent proposal and it
seems to require the creation of far fewer classes and objects:
<http://en.wikipedia.org/wiki/Data,_context_and_interaction>

------
TylerE
For the web, I find Lift's "View-First" setup much compelling, and easier.

The issue I have with traditional web-framework MVC is that it assumes that
each URL associates with one controller, which I've found to be very
straightjacket-esque. Often the pages I'm building have many separate bits of
functionality present, from simple stuff like a login box, numerous widgets,
and then the main thing the page is about.

In lift, each URL maps onto a view, which will contain the templating code for
that page, including perhaps inheritance to pull in an overall template, and
then will contain one or more (and perhaps MANY) snippet invocations.

A snippet in Lift is kind of sort of like a controller method. It takes the
contents of it's template tag as input, and as output returns a transformed
document tree, using what ever resources (models, web service calls, calling
out to other classes, etc) it wants to do that.

If you write the snippets in a general way, binding text off of IDs, this
allows you to get different outputs for the same data, depending on how you
call the snippet - it's like passing a partial template in as a closure. Very
different but powerful - the snippet handles the LOGIC, but only abstractly
the templating.

It's a very powerful paradigm - it frees you from the MVC straightjacket,
since you can arrange and organize your code however you like, but forces very
strict separation of concerns - it forces you to compartmentalize your
business logic, but doesn't force you to do it a certain way. Lift does really
cool stuff with your xHTML/HTML5 templates too - it's truly operating on a
server-side DOM tree, none of this is textual substitution.

[http://www.assembla.com/spaces/liftweb/wiki/Templates_and_Bi...](http://www.assembla.com/spaces/liftweb/wiki/Templates_and_Binding)
for more info.

~~~
SkyMarshal
Second that about Lift too. It's basically server-side jQuery. Instead of
parsing templates as one big string, it does DOM transforms on sub-trees.
Parallel, independent, lazy-loading transforms using an Actor for each for
each Snippet/subtree. Really awesome model.

Also, Twitter's recent 180 on shifting some processing from the client back to
the server [1] suggests a server-oriented framework like Lift's is worth
considering, despite the hype and excitement around client-heavy Rich Web
Apps. Lift does the API-consuming rich client model as well, but its
uniqueness is the DOM transform stuff.

Very different mental model than MVC and hard to get started with for some
because of that, but here's a great bit of advice on best practices I came
across recently (especially the part about pretty everything being done via
either LiftRules or the S object) [2].

1\. [http://engineering.twitter.com/2012/05/improving-
performance...](http://engineering.twitter.com/2012/05/improving-performance-
on-twittercom.html)

2\. [http://www.quora.com/Lift-web-framework/What-are-the-best-
pr...](http://www.quora.com/Lift-web-framework/What-are-the-best-practices-
for-using-Lift)

~~~
TylerE
Yea, having done a two small projects in it now, my brain is starting to adapt
to it a bit. Maybe a bit easier for me than for some, since I never really
bought into MVC all that hard, so I'm not having to break too many habits.

------
twelvechairs
> In a MOVE application models only wrap knowledge. That means that, in
> addition to getters and setters, they might contain functions that let you
> check "is this the user's password?", but they don't contain functions that
> let you save them to a database or upload them to an external API. That
> would be the job of an operation.

I cant understand the distinction between a 'setter' (stated here as part of
the MOVE 'model') and 'functions that let you save... to a database or
upload... to an external API' (stated here as part of the MOVE 'operations').

I would understand the logic a lot more if the 'model' excluded 'setters'
entirely and just included 'queries' (which don't change the underlying data
set) as opposed to 'commands'/'setters' (which do...). As it is I'm not sure
where the line is between 'operations' and 'model' except for the use-cases
that have been explicitly stated.

------
pkaler
In the Objective-C/Cocoa world, Operations are encapsulated using the
Receptionist Pattern.
[http://developer.apple.com/library/mac/#documentation/Genera...](http://developer.apple.com/library/mac/#documentation/General/Conceptual/CocoaEncyclopedia/ReceptionistPattern/ReceptionistPattern.html)

And Events are handled with a combination of Key-Value Observing and UI
binding.
[http://developer.apple.com/library/mac/#documentation/Cocoa/...](http://developer.apple.com/library/mac/#documentation/Cocoa/Conceptual/KeyValueObserving/KeyValueObserving.html)

Controllers still exist but the design of a program is easier to reason about
if everything that mutates data is pulled out of the controller.

UI changes must be made on the main queue, but the above design helps pull out
model changes, network requests, etc on to background queues.

------
Spearchucker
Interesting post.

I've spent the last few years on an piece of software where the model and
controller must be reusable between desktop, phone and tablet.

I started with a layered approach. Then I moved to MVC. After that I
discovered MVVM. I finally ended up with an MVVM/Naked Objects hybrid.

The result is views that make changes to the model via command bindings, and
respond to changes in the model via event bindings. The application (aka
controller) is similarly bound to the model, and contains all business logic.
It's clean, easy to maintain, and easy to test against and debug.

The views are different for each platform (desktop, phone and tablet), the
model and application are re-used as-is.

I guess my point is that none of these approaches (MVC/MVVM/MVP/etc.) are bad.
Each is good within a pretty small scenario window. The trick, probably learnt
through experience, is knowning when to use which.

------
vasco
This looks like a really good way to stop putting all your messy code into
Controllers and start putting it into Operations.

The problem with messy code or where it lives will not go away because you
think about it differently, you just have to either hire better people or
spend more time and money refactoring.

~~~
cirwin
The advantage of operations over controllers is the composability.

Whereas controllers have a pretty undefined lifetime, operations are finished
when they're done. This means that operations can use each other to get work
done, a pattern you don't see with controllers.

~~~
alttab
You can build a set of composable methods that you can use in the controller.

------
specialist
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.

~~~
fadzlan
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.

~~~
specialist
_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.

------
tieTYT
Is there something structured like hacker news that focuses on articles with
content like this? I find this a lot more interesting than threads about
entrepreneurship but I don't know where to go to read about things like this.

~~~
mattgreenrocks
Good question. Architecture doesn't get debated much on the Internet (probably
because it's easier to bash PHP), but here's to hoping there is a place where
people argue about this more.

~~~
alttab
The one thing I care about the most is architecture and system design. These
conversations are largely absent and developers can go years without acquiring
a pallete for this type of discussion. I wish it was discussed more as a lot
of the cost of maintenance could be cut down if spaghetti were properly
avoided.

------
rickmb
"you end up stuffing too much code into your controllers, because you don't
know where else to put it"

And that wouldn't happen to have anything to do with the fact that "you"
either don't know any other patterns or solutions besides MVC, or are under
the impression that using MVC somehow forbids you to use other patterns?

Not to mention the fact that the definition of MVC that the author uses is
false (in a way that describes MVC as more simplistic and limited than it
truly is), but after so many years I'm not even going to argue with that any
more. Just fucking Google it.

tl;dr: Those who cannot learn from history are doomed to repeat it.

~~~
einhverfr
ummm... one nitpick.....

Everyone repeats history. Some repeat the good parts. Others repeat the bad
parts. Learning from history allows us to try to stop repeating the bad parts
and do better with the good parts.

------
pmb
Show me the code. Before I believe this, I'll need to see a codebase that uses
MOVE and not MVC and manages to do things which are not easy in MVC. It's find
to rant and rail against old patterns, but patterns are _de_ scriptive, not
_pre_ scriptive. Once you see a solution that has the same "shape" in a few
different contexts, you might have found a pattern. This puts the cart before
the horse by proposing the pattern before it has been actually used.

------
namank
Umm...what?

What do you think helpers are in PHP MVC frameworks? They are code blocks that
should not go in controllers but are required; like a password generator or
reformatting for print command.

Go use Symfony to see how events and MVC mash up together. They do a good job
in there.

Author's next post will be about including services for
controllers/helpers/actions that are called more frequently. Once again, Mr.
Author, check the PHP framework called Symfony.

------
jaybill
I don't know. This is essentially saying that the way to solve problems is to
add additional layers of abstraction. If you want to see a bunch of examples
of why that's a bad idea, take a look at any J2EE application.

RAPHT
([https://github.com/DanielWaterworth/Raphters/blob/master/RAP...](https://github.com/DanielWaterworth/Raphters/blob/master/RAPHT))
attempts to something similar (adding more layers of abstraction to MVC) but I
have the same problem with that.

If we were really understood the problem we'd have come up with a way to make
things simpler, not more complicated.

I think the real problem is that MVC is understood by different people to mean
different things but they think they're talking about the SAME thing. Back end
developers tend to think of the view layer as a trivial thing ("It's just HTML
and Javascript! How hard can that be?") and front end developers tend to think
of the model layer as trivial. ("Look, my backbone.js code is handing out and
consuming JSON, how hard can it be to persist that?")

------
sakopov
Isn't this what CQRS attempts to do?

[CQRS]: <http://martinfowler.com/bliki/CQRS.html>

~~~
lucisferre
Sort of but nt quite, it feels much more like data-context-interactions.
Really this doesnt kill MVC at all but extends and enhances it.

------
stcredzero
I'm going to go out on a limb here.

With a pattern like MVC, where developers implement it again and again, and
many of these are junior devs, it's highly likely that people who don't
entirely understand the pattern are going to be adding code. The correct use
of the pattern is going to get diluted, and certain classes are going to get
overstuffed with code that often turns into spaghetti code.

I'm not so sure this is the fault of the junior developers. If there is one
"obvious" place to expediently stuff code to implement new functionality then
this is actually the fault of original designers. I don't know of any pattern
for building applications that doesn't fall into this trap, but I think that
one which escapes it is possible through some trick of code organization and
programming language technology.

------
shadowmint
meh.

Doesn't address any of the actual issues with writing an MVC web application.

MVC -> Views are templates, Controllers are HTTP server end point bindings and
Model is everything else.

Rookie mistake; put logic in controller actions. No! This is a terrible idea:
your controller should never do more than: parse input, apply update to some
model object, generate response view model.

'Model' does not mean 'Something that serializes and goes into a database'. It
means everything else. The entire state and _associated classes that
manipulate that state_. That's where these operations from MOVE exist.

I mean, if you want to critize MVC (especially some popular frameworks...), go
for it, but I'd be much more interested to hear how a new approach addresses:

\- What about all that javascript / flash / etc? Where does that fit in?

\- How do you effectively test controllers and views?

------
Avalaxy
The author probably never heard about the 'service layer' pattern. The problem
that 'MOVE' is trying to solve is a non-existing one. If you're stuffing all
your logic in your controller, you're doing it wrong. The logic should be in
the service layer, that's how it has always been.

------
ap22213
I'm willing to try it out.

I usually get around the cited issues through dependency injection into the
model. That is, instead of placing large amounts of logic in the controller, I
let the model hold the logic.

In a naive implementation, this may couple the model to things it shouldn't be
coupled to. So, to avoid the model coupling to infrastructure resources (say,
storage), I let the controller inject those objects into the model, as needed.

But, I realize that that's an architect-y, OO kind of way to do it that
requires some background knowledge which can may obfuscate the code. So, I'm
all about making things easier for everyone.

As others have mentioned, it'd be useful to have a more sophisticated example.

------
jasim
MVC is not dead. It has its warts, but there still is a strong developer
community who build applications using MVC - through MVC based frameworks, and
also by handrolling implementations that are an approximation of MVC. As long
as there are enough people using it, MVC can't be pronounced 'dead'.

As to MOVE, the issue that the author points as the problem with Controllers
in MVC is that'controllers are nice self-contained bits of.. what?'. At some
point people will start asking these questions about 'Operations' and
'Events'. What would you classify as an 'event' vs an 'operation'. Some mature
Rails projects that I've seen already uses this paradigm - there is an
internal synchronous pub/sub event listener to which messages can be pushed by
both the controller and the model. Even then, there is always a question of
where to put what. Some answers are very clear - like an audit log which is
only a side effect. But it is not the case always.

The author is trying to solve this 'classification' problem by giving us a
more granular model. This can help to a certain degree - but there will be
some point where even this wont help us. At that point we can choose go to a
finer granularity, or ask the question whether all this extra organization is
worth the hassle?

Abstractions are not without a cost. Some abstractions are too essential for
any project. Some abstractions are nice to have. But all of them have a cost.
In the case of MVC, the cost of the extra organization is paid many times over
by the increased maintainability of the application. But given the number of
components the MOVE paradigm advocates, I'm doubtful whether the added
organization will be worth the cost.

I agree with what DHH said on a recent podcast - it is easy to talk about
concepts in abstract and they can look really good. But what changes the game
is a real implementation and being able to contrast the code 'before' the
change and 'after' the change. This is not feasible all the time - some things
have to go through the ideation and a slow testing phase. But at the least,
I'm looking forward to see a non-trivial application that uses this paradigm.
I'm ready to try imagining how it would have looked in MVC and decide whether
the extra organization is worth it.

------
smoody
I've replaced MVC with VAM -- View->API->Model. I believe it's best to always
code the "operations" layer as an API layer. The API always acts on models.
Very similar to operations in MOVE, but it clarifies the goals of the layer.

------
beberlei
Very spot on explanation of what is circulating in my head for months now.
This seems to relate to the Data-Context-Interaction movement and what Bob
Martin calls Entity-Boundary-Interactor pattern in his latest talks.

------
arms
I'd be interested to know what language(s) the author is using for these MOVE
applications.

I primarily use PHP, and have gotten in the habit of using a service layer to
handle business operations. I've found that it's worked extremely well, and so
far does not seem restrictive. It's let me clean up my controllers and models
quite nicely.

It's been awhile since I've used the RobotLegs Actionscript framework, but its
'implementation' of the MVC pattern seems awfully close to MOVE.

Overall, I think the author makes a good case of how to improve MVC
application development, regardless of whether the name should change or not
:)

------
semerda
MVC is nothing more then a pattern for component interactions allowing the
separation of information. How you implement it is really up to the developer
but this is the "starting" point for some and for many a guide.

Look at Django, it is often called MVT but yet it follows the MVC conventions.
Maybe the language you are using is forcing you to add beef into your
controllers hence the negative view of this pattern. But ultimately if your
coding in Python you would be abstracting logic code out into your Models and
Modules and only making references to them in the Controller.

------
rossjudson
The interesting part of this is the resemblance of hierarchical operations to
Erlang supervisor hierarchies, without explicitly pointing that out. In fact,
the whole thing feels kind of Actor-like.

------
modarts
How is this different from MVVM? His "events" are basically a ViewModel that
is "observable" (generates an event when the underlying data changes, which
the View listens for.)

------
peter_l_downs
Are there any MOVE frameworks yet? I very much like the idea, but one of my
favorite tests for "correctness" in a program is to use it to build something.
Although it could be (and probably is) a reflection on my lack of knowledge, I
find myself "fighting" with MVC frameworks like backbone whenever I try to use
them. I would love to see if MOVE would be any better.

~~~
algorithmmonkey
MVC may not be a solid pattern for a client side framework. It makes sense to
contain some semblance of state with in the presentation layer on the client
side, rather than working with a stateless MVC pattern.

<http://www.martinfowler.com/eaaDev/uiArchs.html> MVP via M. Fowler seems a
little closer to what client side should feel like (imho).

<http://en.wikipedia.org/wiki/Model_View_ViewModel> MVVM also makes sense for
a client side app, which is just an extension of MVP.

IMO MVC on the client side is just a carry over from people who were
experienced in writing web apps who wanted something that felt familiar on the
client side. It's a leaky abstraction at best.

~~~
alttab
I agree with this. I'm not particularly interested in client-side MVC
frameworks because it wrongly trivializes the server component, and
technically speaking any javascript running on the client is part of the view.

I'm not sure what the right answer is, but I certainly feel like the race for
rich client-side apps had too many frameworks settle on MVC without thinking
about the bigger picture.

------
dougabug
I agree that the controller abstraction is a bit ambiguous, certainly to the
degree that MVC means different things to different people. I thought that the
article would be pure flamebait, but actually it does seem to be more precise
in its terminology, and captures more closely how I generally design software
systems.

------
cbsmith
> Without closures (or anonymous blocks) event binding can be very tedious;
> and without deferrables (also known as deferreds or promises) the idea of
> treating individual operations as objects in their own right doesn't make
> much sense.

Of course, MVC was developed and popularized on Smalltalk.... which had both
of these notions...

------
serbrech
"the "currentUser" model will emit an event to notify your application that it
has changed"

That sounds like more than just wrapping knowledge to me.

Also, why do you absolutely want to fit everything into a framework? Or a
pattern? Business logic goes into your domain models. Don't mix your business
logic with your framework, that's about it...

------
j_col
With regard to the "is dead" proclamation in this title, this comment from a
previous commenter sums up my feeling perfectly:

<http://news.ycombinator.com/item?id=554397>

Once I see "X is dead" in a article title, I stop reading.

------
ary
Arguably Cocoa and Cocoa Touch already have this with the responder chain and
notifications.

------
azylman
Does anyone else think that it's weird for the model to be sending events
directly to the view and have the view listening for those? That seems like
something that should be going to the "operation tree" and having that push
changes to the view.

------
arunoda
There is no new here. You have a point here mvc need some upgrades. But it is
not dead.

You simply divide controller into 2 parts.

1\. Events 2\. Operations

I too find event also can be think as a router. The title is bad. This is not
new. But a good useful practise.

------
lectrick
> 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.

What the hell is he talking about? Has he never worked with Fat Model™ design?

------
agumonkey
For the curious, read the original papers from R.Trygve :
<http://heim.ifi.uio.no/~trygver/themes/mvc/mvc-index.html>

------
grandalf
Operations are just a temporary stop on the road to functional programming.

------
azat_co
Old issues: where to put business logic. Controller, Model, maybe even view?
Why just don't use abstraction layer for business logic? Most people do it
already. Should we call it Operations?

------
rdudekul
As a Node.js developer and a former Rails/MVC developer, MOVE does make a lot
of sense. I will be waiting for a MOVE Node.js framework with good examples to
emulate/use in my Node apps.

------
mempko
The inventor of MVC Trygve Reenskaug understood the problem a long time ago
and invented DCI as a complement <http://j.mp/MskKMx>

------
emmett
When I read suggested code where each class has one "process" or "run" method,
I think that someone who lives in an object-oriented world has reinvented
functional programming.

------
netghost
Seems like a reasonable way to structure an application. It would be great to
see a concrete example or two. The login example that is sketched out gets you
partway there.

~~~
Bootvis
Yes, the proof of the pudding is in the eating. So:

 _Do you haz teh codez?_

The idea in practice gives a much better idea of what the pros and cons are.

------
blakecaldwell
In addition, operations fit nicely into queues, and make undo easier. That is,
a rename operation can queue up an inverse rename operation for its undo.

------
brendoncrawford
This seems to be pretty much the same as MVC, where "Operations" are
controllers and "Events" are essentially routes. Am I missing something?

------
rco8786
Honestly it seems nearly identical with MVC except you call Controllers Events
and Operations are just your business/data layer logic.

------
joshontheweb
I think this is a really interesting idea, it would be cool to have a sample
app to look at implementing your ideas.

------
jhaile
My controllers have one function for each operation. Oh yeah, and they talk to
each other using events...um...

------
arunoda
I say MVC is not dead. I just said it :) <http://goo.gl/kvs7t>

------
notspamguy
MOVE sounds an awful lot like JSF.

------
EGreg
So basically Controller has Operations and Events

Kind of like in MacOS it has methods and delegates?

------
tree_of_item
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.

~~~
asolove
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...](http://www.amazon.com/Smalltalk-Objects-Design-Chamond-
Liu/dp/1583484906)

~~~
alttab
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.

~~~
cbsmith
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.

------
rorrr
So you renamed "controllers" to "operations".

~~~
pestaa
It splits controllers into operations and events.

Out of the three terminologies (state, representation, flow), the third one is
arguably the most tangled. I find it healthy to refactor it into reusable
chunks (operations) and event-driven flow management.

The problem was, in my opinion, that operations should have not been put into
controller units. It attracted more copy-paste solutions in my experience.

~~~
utilitron
What is the difference between that and adding a service layer to a MVC?

~~~
rcgs
There isn't, but then is MVC really MVC when you've added in another layer?

------
shasty
Sorry, composable operations and models firing events is bullshit. The article
is somewhat correct in that true MVC is dead in practice, however, service
oriented architectures have already filled this void.

Eventing is HORRIBLE. Regardless of the source, but models especially are not
the place to be firing events.

This was all tried years ago. Before writing an article purporting to replace
a foundational concept in application development maybe do a little more
research into what the actual practical solutions to these factoring problems
are.

------
benihana
Seems like the Operation layer is a combination of controllers and business
logic, which feels like a bad idea to me. If the models only wrap knowledge,
but don't do any work, then it's the part of the Operation to both decide what
to show and also get it in the correct format to show. This seems like it's
doing too much and is analogous to the MVC problem of really fat controllers.

~~~
goblin89
On a flip side you can get models that do too much. At one point I had a
method on a model that, in order to get data into correct format, just went
and rendered a [Django] template. It came to that naturally, the line is thin,
and I now prefer to err on the side of models doing too little.

> it's the part of the Operation to both decide what to show and also get it
> in the correct format to show

Did you mean Views, not Operations, here? Or maybe I'm missing something.

------
wissler
I've always thought MVC was a joke played on gullible software engineers,
kinda like this:

<http://en.wikipedia.org/wiki/Sokal_affair>

------
michaelochurch
I like this. I'm not a UI expert in the least, but I've always felt that the
"controllers" component was a bit ill-defined. It seems that the MVC division
comes from a time when GUIs were for single-agent, deterministic desktop apps
like calculators.

In a world where "social" apps are increasingly important (and this time I use
"social" non-pejoratively, because even if 99% of "social" is crap, the other
1% is damn important) and notifications need a first-class status, MOVE (the
separation between operations, which are agent-initiated, and events, which
are observed and can come from anywhere) makes sense.

------
tubbo
Can't wait for the first MOVE framework to come out: "Mumia"

------
vtry
Try AngularJS, that's MVC done right.

------
hmans
lol, objectify.

------
detay
<http://xkcd.com/927/>

------
Produce
I stopped reading right around here:

>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.

What was that? You stuff all of your logic into controllers then claim that
MVC is broken? Your ugly face is broken. Uglyface.

------
rglover
Wow. As a designer who recently took the plunge into learning MVC (via
Ruby/Rails), this is incredibly easy to understand. It took a bit of thinking
to understand MVC but for some reason, separating out the concept of
operations/events makes it blatantly obvious.

Now an important question: how would you practically implement this? Would
this dicate a separate framework/language altogether or something else (I have
a cursory knowledge of development, so play nice)?

 _Edit_ Just noticed the footnote at the bottom of the article linking to
these: <https://github.com/bitlove/objectify> and
[http://collectiveidea.com/blog/archives/2012/06/28/wheres-
yo...](http://collectiveidea.com/blog/archives/2012/06/28/wheres-your-
business-logic/)

