Backbone.js Is Not An MVC Framework

原文地址： http://lostechies.com/derickbailey/2011/12/23/backbone-js-is-not-an-mvc-framework/

Backbone.js Is Not An MVC Framework

Posted by  Derick Bailey  on  December 23, 2011

I’ve seen this question / statement / argument more than a few dozen times. I don’t particularly care whether or not people try to understand Backbone in terms of MVC frameworks, because that’s how we learn. We adapt new ideas based on existing knowledge experience, before we fully understand the new idea. However, I do care that people continue to say Backbone is an MVC framework, because it confuses people when they don’t see a “Controller” and see things like “Routers/Views are sort of a controller“.

I’m not going to “set the record straight” or try to offer the definitive answer on this, though. I’m not a core contributor to Backbone. I didn’t build it and I don’t have any say in how it’s truly architected and designed. So, none of what I say is official. I am going to offer my opinion, though. I feel my years of experience in working with MV* family applications at least gives me enough knowledge to do that… which, honestly, is only going to muddy the waters more because I seem to be in the minority on this opinion.

There Are No Controllers In Backbone

There simply aren’t. In spite of the documentation saying that routers or view may be sort of maybe almost kind of close to some of what a controller might do, there are no controllers. It’s not a construct that exists in the backbone namespace, and there’s no implementation that represents what a controller does, architecturally.

A router is not a controller. It’s a router. A view is not a controller. It’s a view. Yes, both routers and views share some of what a modern web-server MVC framework, such as Ruby on Rails, would call a controller. But neither of these is a controller.

More MVP Than MVC

I’ve spent 5+ years building MV* family applications in thick-client / GUI systems (Windows / WinForms / WinMobile) and on the web (Rails, ASP.NET, ASP.NET MVC, etc). Backbone clearly fits in to this family, but it’s also clearly not MVC. My opinion says that it’s closer to MVP, where the backbone view is closer to a P (presenter) and the HTML/DOM is the V (view).

Consider this picture of an MVC process flow (from Wikipedia):

Here, the models contain data which is used to populate views. Actions that a user initiates are handled by the controller which processes the request and updates the models. The models are then fed back to the views and the cycle starts over. It’s cyclical in nature.

And now consider this picture of an MVP process flow (from LessThanDot.com):

Notice the difference? Right – it’s not circular. That’s the big difference between MVC and plain-jane MVP (a.k.a. “passive view“). MVP does not work in a circular fashion the way MVC does. Instead, it relies on a presenter (the “P” in MVP) to be the coordinating brains of the operation. The presenter in an MVP app is responsible for taking the data from the models and stuffing it in to the views. Then when an action is taken on the view, the presenter intercepts it and coordinates the work with the other services, resulting in changes to models. The presenter then takes those model changes and pushes them back out to the view, and the elevator of moving data up and down the architectural stack begins again.

Does the idea and responsibility of a presenter sound familiar when thinking about Backbone? It should… it fits almost concept for concept with Backbone’s views, in my mind. But that doesn’t mean Backbone is an MVP implementation, either. It only means that views should be thought of as presenters, not controllers.

Neither MVP, Nor MVC, Nor MVVM, Nor …

Ultimately, trying to cram Backbone in to a pattern language that doesn’t fit is a bad idea. We end up in useless arguments and overblown, wordy blog posts like this one, because no one can seem to agree on which cookie-cutter pattern name something fits in to.

Backbone, in my opinion, is not MVC. It’s also not MVP, nor is it MVVM (like Knockout.js) or any other specific, well-known name. It takes bits and pieces from different flavors of the MV* family and it creates a very flexible library of tools that we can use to create amazing websites.

So, I say we toss MVC/MVP/MVVM out the window and just call it part of the MV* family. Or better yet, let’s just call it “The Backbone Way” and forget about trying to fit some cookie cutter mold around a fluid and flexible library.Then we can focus on what Backbone actually provides and how these pieces should work together to create our apps.

About Derick Bailey

Derick Bailey is an independent consultant, software developer, writer, blogger, speaker and technology leader in central Texas (north of Austin). He has been a professional software developer since the late 90's, and has been writing code since the late 80's. Find me on twitter: @derickbailey,  @mutedsolutions,  @backbonejsclass Find me on the web:  MutedSolutions.com,  BackboneTraining.net,  WatchMeCode

View all posts by Derick Bailey →

This entry was posted in  Backbone,  Design Patterns,  Javascript,  Model-View-Controller,  Model-View-Presenter. Bookmark the  permalink. Follow any comments here with the  RSS feed for this post.

← Composite JavaScript Applications With Backbone And Backbone.Marionette

Automating Docco Generation And Deployment To Heroku And Github →

• http://twitter.com/demisbellot Demis Bellot

  >>More MVP Than MVC

  I don’t agree.

  I believe Backbone more closely resembles the original MVC GUI paradigm as existed before MVC web frameworks changed its meaning:http://martinfowler.com/eaaDev/uiArchs.html#ModelViewController

  • http://mutedsolutions.com Derick Bailey

    Like I said: bits and pieces of many flavors of MV*, not MVP or MVC, my opinion, and useless discussions that don’t get us anywhere. The point of the article is at the bottom.

  • http://mutedsolutions.com Derick Bailey

    and FWIW: I agree with you. I wasn’t considering the old-school MVC, though, as that’s not what people refer to when they say MVC, in general. I usually hear people say “SmallTalk MVC” when they refer to that.

• Lance Harper

  What about Spine.js?

  • http://mutedsolutions.com Derick Bailey

    I don’t have enough experience with spine to say much about it. I’ve only looked through the docs and played with a few samples, a few times.

  • Blake

    In spine, the controller is similar to the view in backbone. Collections and models are consolidated and instantiated/managed on a more global scale. Other than that the patterns are the almost the same. Controller creates views and subscribes to changes on models in order to update.

• Mike

  I propose a new acronym MVS, Model-View-Something

• http://twitter.com/stevemgentile Steve Gentile

  Just a thought, but because of no controller or presenter, we end up needing things like Marionette to provide view switching, etc…?

  IMO, I view that part of Backbone ‘out of the box’ as being incomplete.  Although you could say he just left it open for others to implement the controller/presenter/viewmanager.  Once your app starts to go down that composite route we are in need of these ‘missing’ pieces

  • http://mutedsolutions.com Derick Bailey

    Yeah, I think that’s part of the downside of open and flexible libraries like Backbone. If Backbone provided an application layer it would likely become more prescriptive in how you have to do things… like Sproutcore or Batman.js. There are plenty of benefits, but also some drawbacks, to both situations. Open and flexible, but less guidance and a few missing pieces… or more prescriptive, but with all the pieces right there in the framework for you.

• gabriel

  Change Backbone.View to Backbone.Controller. What do you think?

  • http://mutedsolutions.com Derick Bailey

    No… calling an orange a hammer doesn’t mean you can pound a nail into wood with an orange.

    I could get behind renaming it to Backbone.Presenter, for the reasons I’ve stated above, though.

    • http://www.facebook.com/ron.reiter Ron Reiter

      Derick, Backbone.View IS AN MVC CONTROLLER, it’s just a poor choice of words. The view in HTML models is the HTML and CSS which the Backbone.View (the Controller) handles!

      Read my presentation to see an image which explains the relations:http://www.slideshare.net/ronreiter/writing-html5-web-apps-using-backbonejs-and-gae/
      TBH, it’s quite simple once you accept the fact that Backbone.View is a controller. BTW, check out Android programming, they do something really similar – there, the Backbone.View is called an adapter.

      • http://twitter.com/plapinhh p l

        Why must one accept something doesn’t like to be this??? ;-)

        Controller in MVC (we are talking about its original in Smalltalk-80, aren’t we?) didn’t have some functions the BB.View have. The View was more active about data fetching, its state holding and manipulating itself. All this we don’t have in BB. The View ist simple markup without logic. All logic about presentation is bound to BB.View. So I can see BB implementing MVP and brings some nice features for data layer with.  

      • http://mattbriggs.net Matt Briggs

        In MVC, a view wires itself to the controller, and changes as the controller changes. The controller has no reference to the view. In MVP, the presenter reaches into the view and messes with it, and can also talk to other presenters.

        I don’t think these discussions are super important, but I would highly recommend reading http://martinfowler.com/eaaDev/uiArchs.html

• Luc Perkins

  I argue here that Backbone does have an implicit and somewhat creepy deus ex machina controller:

  http://blog.appfog.com/putting-some-mvc-meat-into-your-app-backbone-js/ 

• Chance

  Here is the controller for Backbone.js : http://chance-an.github.com/backbone-mvc/

• Vlad

  Hi Derick!
  I have 1 small question/suggestion. When you say

  “A router is not a controller. It’s a router. A view is not a controller.
  It’s a view. Yes, both routers and controllers share some of what a
  traditional MVC framework would call a controller”

  I think the 5th sentence should be corrected to “yes, both routers and VIEWS share some…”.

  Or did you really mean “controller” as old name of router in Backbone?

  • http://mutedsolutions.com Derick Bailey

    Yes, you’re correct. I meant to say “views”. Fixed. Thanks! :)

    • Vlad

      cool :)

• Guest

  By now the term MVW (Model-View-Whatever) has already been coined and the carrot that is isomorphic javascript, or JS that runs both on the client and server, is furiously being sought after. Will Flatiron the first one to the finish line?

  http://blog.nodejitsu.com/scaling-isomorphic-javascript-code

• Guest

  By now the term MVW (Model-View-Whatever) has already been coined and the carrot that is isomorphic javascript, or JS that runs both on the client and server, is furiously being sought after. Will Flatiron be the first one to the finish line?

  http://blog.nodejitsu.com/scaling-isomorphic-javascript-code

• http://www.habdas.org/ Josh Habdas

  By now the MVW (Model-View-Whatever) has been coined. More patterns have emerged and the carrot, still dangling, seems to be isomorphic javascript:

  http://blog.nodejitsu.com/scaling-isomorphic-javascript-code

• http://twitter.com/brokenseal Davide Callegari

  Hi,

  I know this is an old post but I found it during my googling and I’d like to give my thoughts on it.

  I find Backbone appealing because I come from a Django background and I find it very similar to it, since Django has its own router (a urlpattern tuple), a set of templates, views that are responsible for rendering a template and models.

  Django refers to itself not strictly an MVC but MTV (Model-Template-View), which is a bit different but from the same “family” of frameworks.