I read the anti SL article and maybe I build things a little differently, but I tend to build applications that interact with services differently depending on

I read the anti SL article and maybe I build things a little differently, but I tend to build applications that interact with services differently depending on what layer they belong to. 1) Application entry: create context and provide to top tier participants. Creates the service locator and provides to children. 2) top tier participants: Command/Request routing and configuration. Receives service locator, provides concrete services to children 3) features: plain old functions (or classes) that recieve dependencies when called or constructed. No frameworks necessary. Start up is fast. Things mostly get built/called only when needed. My service locator generally just looks like a bag of getters. Some of which operate like a Singleton, others return a new instance every time. Testing is easy and obvious. There aren't a ton of places where args are being painfully or magically forwarded. I've had this pattern work for UIs, servers and embedded projects. It's super fast, ergonomic and light weight, but most importantly, testable. Maybe all the fuss is about C#/Java magic entity registration and creation frameworks? If that's the case, then maybe I agree? IMO those feel like a promising experiment that didn't work out great in practice. I've built systems (even recently) where too much stuff found it's way into the SL, and can agree that's not good. Nowadays, I just put the things in there that one would be tempted to make a Stinkleton out of. 1's or at worst, 10's not 100's of things.