The way to manage this without DI would be a static method someplace (Startup.cs or elsewhere) which creates the new MyService, stores it, and returns a reference. Then any controllers or pages that need the reference call the static method.

The method could return a MyService, or an IMyService if you want to be more flexible. It can always create a fresh object, manage and return a singleton object, or manage a pool of objects. For the new and pool cases, you can have another static method for 'returning' the object when the controller/page is done with it, so you can manage disposal or pool availability.

The biggest advantage I see to this approach is in debugging: there is a clear stack trace back to the source of the object, and also to its implementation if you're not using an interface. With DI you often can't tell where an object came from, and sometimes it takes some digging to even find out its exact type (unless you only have one implementation of each interface, which is often the case.)

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>();