+1 for having your model clean and passing in the setting.
Just because it’s Friday and I feel like bantering— I (somewhat) often inject settings into my model and I have no issue with it.
Here’s my rule of thumb:
The contract (API) between the handler and the model’s methods should only encompass arguments directly related to what the model is doing for the handler, especially pertaining to behaviors the handler needs to have control over. As the model is to a degree, a black box from the handlers perspective, the handler (or any other caller for that matter) should not be taxed with knowing internal dependencies required by that method which are orthogonal to the outward task which is is performing.
For instance, consider a CompanyService object with a getCustomLogoURL() method. Let’s say the method generates the fully qualified URL of a given company’s logo based on the ID of the company in question as well as a flag indicating whether or not to return an HTTPS URL.
function getCustomLogoURL(numeric companyID, boolean makeSecure = false)
{
…
}
Now, imagine that the function in question uses a site-wide CDN base domain stored in a ColdBox setting which is concatenated to the path and image name to generate the full path at run time.
I would consider it bad practice (this this instance) to add that CDN base domain as an argument to the getCustomLogoURL method, thus requiring every caller of that method to have knowledge about HOW the URL is generated internally, especially when it is not configurable on a call-by-call basis, but rather set once for the entire site.
I personally would wire the setting directly into my CompanyService so it is available directly to the method, and let callers of that method only concern themselves with arguments pertaining to the inputs they have control over and care about.
var URL = CompanyService.getCustomLogoURL(companyID = 123, makeSecure = true);
Furthermore, imagine the chaining nightmare that could be created when nesting method calls, if the outer-most call was required to pass along settings that may or may not be required at a deeper level.
i.e.
handler calls: GenerateHTMLforPrintablePDFCertificate()
----calls: generateHeaderHTML()
--------calls: generateLogoHTML()
------------calls getCustomLogoURL() conditionally if custom logo even exists.
The example is a bit forced (and I probably wouldn’t use service calls to generate HTML either), but the point is I wouldn’t want the upstream methods to need to pass along seemingly unrelated bits of data needed by the internals of a downstream method just for the sake of wiring the setting into the handler.
One gotcha’: this does tie your model to your framework, but I’m ok with that as I use all kinds of framework-related things such as WireBox, CacheBox, and the InterceptorService directly in my models.
Obviously this is only one example. You would need to examine your code on a case-by-case basis to determine where it makes sense to inject your dependencies.
/End_bored_Friday_afternoon_rebuttal
~Brad