Hi, perl programmer wannabee here;-) Hope this question is suited for this list. In the examples of Dancer apps I've seen there are no separate Controller classes. The sub() handlers of the routes act as a sort of mini- controllers in the examples of the documentation. But as I am starting on a project that would grow in size, I'd like use full controllers classes, like for a dashboard view that pulls in data from many data source. Where do I fit the controller classes hierarchy in? I’ve found his article http://fraley.de/2013/10/18/structuring-larger-dancer-applications/ that gives a starting point, the sample code is here https://github.com/pwfraley/DancerPrelaunch In the Fraley code, the idea of a central routes table is done away with. Instead, each controller defines its own routes it responds too. Good de-coupling practice, I suppose. But I like the default central MyDancer::App.pm package with a central routes table: - For one, it gives me in a glance an overview of all routes, the whole structure of the app. - But even more, it allows for constructs like ‘pass’ to group routes, conditionally skip routes (when not logged in or no session). - It provides a central lookaction for ‘hooks’ , process params, logging etc. (but a a base superclass Controller could be the place to do that too). On the examples of fraley.de , each controller has its own proper routes defined, but how do you combine that with the generics (loggedin, session, hooks, error) without repeating boiler plate code in each controller? To be more specific, I intend to structure my app along route definitions like: use MyDancer::Controller::FoobarController; get ‘/Foobar/jump’ => sub { my $fb = FoobarController->new; $fb->jump; }; Is this okay or ‘ugh’ ? Any more considerations or advice or pointers on how to organize a Dancer2 app with controller classes are welcome! ~henk