I Never Break Encapsulation (almost)
One of the larger systems that on which I work runs multiple sites from one code base. Each site needs to have some data that is specific to that site. For example, each site should use a different from email address and mail server when sending email.
During the initial development of the system, I decided to give each site its own application scope. After that, I don't have to worry about which data is site-specific and which isn't. Despite a continually growing number of sites, this has worked pretty well for more than five years.
Then the use of one of my own open source projects revealed a problem with this approach.
If you look at BlogCFC for example, I was just thinking about this about an hour or so ago, because I'm considering creating a BlogCFC plugin for the onTap framework that would download, install and configure BlogCFC to run within an onTap framework application. The issue that I'm running into here is that BlogCFC5 is like a lot of ColdFusion applications, it has no Dependency Injection (DI) factory to manage its singletons, and so the singletons are all just placed directly into the application scope, like application.blog, etc. And there are even some just flat-out variables in that scope as well, like application.imageRoot (which is kind of bad too because it's set to the value of a property from the object application.blog, so not only is it breaking encapsulation, it's also duplicating the data and breaking DRY).
So my conundrum with BlogCFC is what do I do with the "client" code (the views), because they're lousy with references to application.this and application.that. I'm contemplating the possibility of an installer that would copy and then manually replace all the references to the application scope with equivalent references to the framework's IoC manager. I don't have to worry about the CFCs, because they're all good on encapsulation. But this isn't a small app (anymore), and the client code is huge. We're talking about manually replacing all the application scope references in about 170 individual files. A DI Factory in the application (even a very simple one) could have made that much, much simpler (and better encapsulated), but then, so would have something like your EvilDecapsulation.cfc.
So long-story-short, I think you've got it kind of backwards. I think you're thinking you're doing something "bad"(tm) when in reality you're doing something good that a lot of folks overlook.
That is an interesting perspective and one I hadn't much considered. As it happens, I do refer directly to Application scoped singletons in my .cfm files (even though I use an DI engine for passing references between the components).
What challenges do you think this practice creates? Do you always get the components from the DI engine every time? If so, is it not stored in Application scope?