<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Thu, Jan 23, 2014 at 2:18 PM, Warren Young <span dir="ltr"><<a href="mailto:warren@etr-usa.com" target="_blank">warren@etr-usa.com</a>></span> wrote:</div>
<div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
Ideally, I want my top-level module to be as small as possible, doing little more than set up the route handlers, delegating all the real work to other modules.  To do that, I need to know where these objects come from, their exact data type, and which package's namespace they live in.  Then I'll know how to reference them or pass them around to the modules that do the work in my app.<br>
</blockquote><div><br></div><div>When you say "the modules that do the work in my app" I'm assuming you mean the model in an MVC architecture. If so, keep in mind that it's very difficult to maintain the code if you pass the route handlers' objects into the model's methods.</div>
<div><br></div><div>An better approach is to implement the model separately from the Dancer DSL, giving it a command-line interface and unit tests. Once that's complete, call the model from the route handlers using data retrieved from the controller using calls like "params". This will make it much easier to identify bugs and make changes down the track - knowing that the impact is limited to the layer in which you're making the change/identifying the bug.</div>
<div><br></div></div></div></div>