On Aug 21, 2017, at 9:52 PM, Nathan Bailey <w...@polynate.net> wrote:
>
> I get the sense that we are using Main.pm very poorly and a bit of Dancer2
> architectural insight would greatly improve the quality of our code.
You might benefit by reading through my “Medium-Scale Dancer” article series
from this past year’s Perl Dancer Advent calendar, then:
http://advent.perldancer.org/2016/3
http://advent.perldancer.org/2016/4
http://advent.perldancer.org/2016/5
http://advent.perldancer.org/2016/6
http://advent.perldancer.org/2016/7
> What is the best pattern for the breakdown between perl module/Dancer2 route
> handler/TT file?
That’s covered in part 2 of the series linked above.
> For example, if you have a sub-system for administrators that manages the
> fees tables and reports, would you put these into separate route handlers?
> eg.
> ReportsHandler.pm => Route handler for reports
> - Instantiates an instance of Reports.pm in it's "before" hook so we only
> need to do this once (or in the module itself?)
I think you’re getting a long way away from Dancer here.
I suspect you’re trying to architect your entire application in terms of
Dancer, whereas Dancer proper is likely only one element in your application’s
overall functionality. That is to say, you have an application that *happens*
to present its user interface via a dynamic web site, but there are many
elements of the application that are not a web app per se.
You should be building the application in layers. Everything you speak of in
the above quote seems to belong at least one layer down beyond the UI elements
you deliver via Dancer.
Those layers and interfaces may be mirrored to some extent in the route
definitions, but don’t feel bound to do that mirroring, much less to couple
business logic to route handlers. Given the cost of HTTP round-trips, there is
great incentive for the route definitions to map one-to-many to internal API
calls.
The old CGI/PHP/ASP model is an extreme example of this: make a single HTTP
request and get back a completed UI, then submit some information and get back
another whole UI. Dancer doesn’t change the fundamental limitations imposed by
network round-trip times.
> But at the moment, each route handler is 20-30 lines long - I think they
> should be ~5 lines long or less.
The article series covers that as well: most of my route handlers are *one*
line long.
_______________________________________________
dancer-users mailing list
dancer-users@dancer.pm
http://lists.preshweb.co.uk/mailman/listinfo/dancer-users
