Skip to content

Consider Removing CommonServiceLocator #1

Open
@WonderPanda

Description

@WonderPanda

First off, just wanted to thank you for such awesome blog posts and sample code to work against when it comes to setting up proper unit testing scenarios for Serverless apps. I've been setting up some function apps for testing based on some of the patterns that you've demonstrated.

One thing I've come against is difficulties in properly consuming the CommonServiceLocator. There were a ton of Nuget package nuances for versioning to get things to work properly in my Function app but then ultimately I'm left feeling like the resolve mechanisms exposed by this locator are so weak compared to what's available directly through AutoFac. Without access to things like ResolveKeyed I'm having to wrap a lot of dependencies inside of classes that wouldn't need to be otherwise so I can resolve distinct items.

Since your Service Locator implementation is strongly tied to AutoFac through the RegisterModule stuff I propose that there is no need for CommonServiceLocator at all. It would be much easier to expose the IContainer from builder.Build() instead. It would be just as easy to Mock for unit tests as IServiceLocator and would give access to the full power of AutoFac resolution. At it's heart, it's still using the Service Locator design pattern as the IContainer needs to be statically available from somewhere. However, it would remove the need for the extra Nuget package and expose a much more powerful API to the rest of the application at the same time.

Curious to know your thoughts!

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions