Added support for alternate strategy pattern to resolve service types

[mythz]

Hi Group,

As a few of us here were interested, I've just checked in an ability to inject a different strategy for resolving service types.

AppHostBase / AppHostHttpListenerBase now have an overridable method to be able to customize the ServiceManager used to load and configure ServiceStack services.

Basically you can now return a ServiceManager and provide your own Funq container and strategy to resolve service types, see the example in comments:

https://github.com/ServiceStack/ServiceStack/blob/master/src/ServiceStack/WebHost.EndPoints/AppHostBase.cs

protected virtual ServiceManager CreateServiceManager(params Assembly[] assembliesWithServices)

{

return new ServiceManager(assembliesWithServices);

//Alternative way to inject Container + Service Resolver strategy

//return new ServiceManager(new Container(),

//    new ServiceController(() => assembliesWithServices.ToList().SelectMany(x => x.GetTypes())));

}

I hope this will be able to support the use-cases for the devs who were asking for this - if not let me know.

Cheers,

Demis

[Brandon Wallace]

Great! Thanks for the addition. And also thanks for the Disposing of
IDisposable services change.

About the types that the delegate returns. I assume it should be
returning the Types which implement IService<T>?

Brandon

[Demis Bellot]

Yeah the services should return IService<T> at a minimum, and the IRest*<T> interfaces if you want to call different methods for the different HTTP verbs.

It's too critical a component to attempt to abstract it out, and there's no value in it.

You should still be able to effectively hide the dependency by getting subclasses to use your own API in your own base classes. 

Moving to a different host should still be easy seeing that IService<T> is effectively just a generic interface for a command pattern, (i.e no reason why you can't create an adapter to your preferred host/fx even using that interface). 

Although you can still eliminate all traces of ServiceStack and the dependency entirely after the fact by a simple re-compile (after removing the IService<T> Dependency) of your base class library which should be drop-in replaceable since user services won't be binded directly to the IService<T> API (i.e. they bind to your own equivalent methods) it should remain binary compatible with the new dll.

Cheers,

--
- Demis

http://twitter.com/demisbellot

http://www.servicestack.net/mythz_blog

[Demis Bellot]

Actually I should clarify on the behaviour of the resolveServiceFn: 

It can return all types of your assembly but it only uses/registers types that implement IService<T> (i.e. service types).