Whats the Advantage of Marionette AppRouter+Controller over Backbone.Router?

Question

From my understanding, the differences is the callback functions to events on an AppRouter should exist in the Controller, instead of the same Router object. Also there is a one-to-one relationship between such AppRouter & Controllers, all my code from Router now moves to Controller, I don't see too much point of that? So why use them? I must be missing something?

Unsnap

Well you can split your router in many little controllers and attach them to a module for istance, to keep things organized... it's just more flexible. – Roundtheclock

I can also have many normal Backbone.Routers right? They will fulfill a similar purpose? – Unsnap

+1 - I've often wondered this – Notogaea

Answer 1

The way I see it is to separate concerns:

• the controller actually does the work (assembling the data, instanciating the view, displaying them in regions, etc.), and can update the URL to reflect the application's state (e.g. displayed content)
• the router simply triggers the controller action based on the URL that has been entered in the address bar

So basically, if you're on your app's starting page, it should work fine without needing any routers: your actions (e.g. clicking on a menu entry) simply fire the various controller actions.

Then, you add on a router saying "if this URL is called, execute this controller action". And within your controller you update the displayed URL with navigate("my_url_goes_here"). Notice you do NOT pass trigger: true.

For more info, check out Derick's blog post http://lostechies.com/derickbailey/2011/08/28/dont-execute-a-backbone-js-route-handler-from-your-code/ (paragraph "The “AHA!” Moment Regarding Router.Navigate’s Second Argument")

I've also covered the topic in more length in the free preview of my book on Marionette. See pages 32-46 here: http://samples.leanpub.com/marionette-gentle-introduction-sample.pdf

Tempura

Why not just make your controller an extension of backbone router and then you can put the routes hash in the controller? If the router and controller have a one-to-one relationship, and all the route methods have to match method names that exist on the controller, then you arent really achieving any modularity/decoupling/separation anyways. And how many lines is your average routes hash? 5 lines? I really dont think 5 more lines is going to add much clutter to the controller. I love Marionette for its view management but some of the app-level stuff seems like pointless obfuscation to me. – Covert

5 lines may not add much clutter to the controller, but you're completely dispersing your URL management. Where does "#contacts/3/update" end up? Maybe it goes to your "edit" controller and uses that view. But maybe it goes to a "list" view with that contact's line having an in-place edit form... You don't know, and grepping for URL strings will not be an enjoyable development experience. – Tempura

By separating things into smaller sections, it makes large applications manageable. The argument yuo make could be extended to views: if controller actions map to a view, why not put them in the controller? Because then you end up with the same javascript soup you're trying to avoid when using a framework like Backbone/Marionette. In other words: divide and conquer! See also lostechies.com/derickbailey/2012/06/04/… – Tempura

"but you're completely dispersing your URL management." - In backbone router route hashes, aren't all the methods mapped to that very same router? seems like this issue is already enforced – Covert

"if controller actions map to a view, why not put them in the controller?" because you can have multiple views per controller, so its good to keep view methods in the view that uses them. But that isnt true for approuters, which can only have one controller anyways. All the controller methods mapped from an route hash have to be in one object whether or not that object contains the route hash or the route hash is in a different object. the only difference with approuters is that youre moving the route hash out to a different object which contains nothing else but the route hash – Covert

Answer 2

I made some override for the router. And currently use it in this way (like Chaplin): https://gist.github.com/vermilion1/5525972

appRoutes : {
  // route : controller#method
  'search' : 'search#search'
  '*any'   : 'common#notFound'
},

initialize : function () {
  this.common = new Common();
  this.search = new Search();
}

Photokinesis