Having trouble with tight coupling of Marionette.Application

[Naresh Bhatia]

Looking at the example in David Sulc's book, I am bothered by the dependency of most modules on ContactManager, the Marionette.Application object. For example, contacts list controller, which is a component deep inside the application, is dependent on ContactManager. For most part, the dependency is due to the fact that ContactManager is an EventAggregator and events triggered by it need to be handled by most modules. In addition, the application is the holder of regions that the components need to render into. I generally see the Application object as a holder of components and that the components should not be dependent on the application itself. Am I thinking about this incorrectly?

To elaborate a bit more, I am generally ok with application components using infrastructure services such as event aggregation, persistance mechanishms etc. But it appears that in case of Marionette, the Application object is both a container of components as well as provider of infrastructure services. Do you think we could get a better (decoupled) architecture, if such infrastructure services would be taken out of it?

Again, I am a newbie to Marionette and trying to understand the best practices as fast as I can. Any help would be much appreciated.

[Naresh Bhatia]

Any thoughts on this? In your experience have you found a heavy dependency on Marionette.Application in your applications? Does it cause any issues? Just trying to figure out how to best structure my apps.

Thanks.

[Roberto Guerra]

You do not have to couple them the way it is done in the book. I think the book did it that way mostly for educational purposes. The only thing attached directly to a Marionette module in my apps are:

1. The Root Application.

2. Very high level controllers that instantiate other objects or controllers that are not directly attached to the module. No view is attached to the module, and no controller for that view is attached directly to the module.

That's been the approach I've taken for the same reason you mentioned above.

[Jeremy Mcleod]

Agreed. We're using AMD modules loaded by requieJS, and one such module is a "super vent" - that is, it's a standalone Marionette.EventAggregator with the "commands" and "request response" behaviors from BackBone.Wreqr included. The application can define it as a dependency, as can any other module, and you can use the RequestResponse object to request the Application's "Region" collection from any module depending on the "super vent."

[Naresh Bhatia]

Roberto and Jeremy,

Thank you for your insights. I feel a lot more confident about my direction now.

Naresh