This is well known Service Locator anti-pattern. Described in many places, maybe this one is the most famous https://blog.ploeh.dk/2010/02/03/ServiceLocatorisanAnti-Patt...

It seems like GP meant a static method specialized to whatever resource the program needs rather than a pluggable factory. All of the issues in that post appear to arise from the fact that they expect the locator to need configuration before it will work, while my reading of GP is that their configuration is which type the method returns, no registering a class or allocator necessary. Yes, this restricts you to a series of services known at build time, but... it seems to me that you knew what your services were anyway, whether it was directly in the locator, in an xml file, or in a registration call.

Absolutely nothing in that blog post applied to what I intended, because I did not say that a generic method that looks up implementations in a registry should be used. My static method would be explicitly coded to return a particular implementation, and there would be a separate static method for each kind of service you need. (Eg: one per interface if you're using interfaces for the return types.)

No registration or configuration is needed, because the types are hard coded. If you need mocking support, a single IsTest config setting could be used in a conditional statement to determine which implementation to return.

That's very little additional coding if you use a ternary statement, and it lets you opt-in to the mocking mechanism if/when/where you need it, instead of permiating your entire architecture with it.

Nah, ServiceLocator is another overly abstruse pattern.

What you do instead is just:

public static IMyService myService;

public static IMyService getMyService() { if myService return myService; else if(isInTest()) return mockedMyService; else return new MyProdService(wtv); }

And call that in your controller that needs to use MyService.

Above code is the servicelocator pattern. It's just for one service.

ServiceLocator has you create a runtime service registry where you can dynamically register and fetch instances too and from. And often that means it bypasses static type checking, as you might be adding and fetching services by name using a string.

This is different in that it's static. You don't add a service to it, it creates it the first time you ask for it (if singleton), or everytime you ask for it (otherwise), or pools it, etc.

I recon some similarities, but most enterprise "service locator" involve a lot more than this, and often are meant to give you this runtime dynamism where you can load and unload services as the app is running, etc. making them way more complex for apps that don't care about this.

Actually, as written, myService never gets set, but I think I know what you mean. This is not thread-safe and assumes you want singleton. To use it you would in each controller do:

var service = Startup.getMyService();

And potentially know if the controller should dispose service.

This doesn't seem much less "in the way" or "massive" than:

services.AddSingleton<IMyService,MyService>();