Understanding scope in a stateless service. about autofac.servicefabric HOT 6 CLOSED

Yes, in the case of a stateless service its lifetime is essentially a singleton. The primary reason for supporting these in the integration is to provide a consistent pattern for working with DI in all types of SF services. You can also use the more natural IDisposable pattern and have the container dispose the appropriate services for you when the service is deactivated.

If you want to have dependencies that should exist only for the duration of a method invocation you can achieve this using an auto-generated factory (Func<T>). In the case that you need to control disposal of this dependency you can also combine that with an owned dependency (Func<Owned<T>>) and dispose the instance of T immediately after you have finished with it in the method. You can find out more about these relationship types on our documentation site.

http://docs.autofac.org/en/latest/resolve/relationships.html

In the example you provided a basic auto-generated factory approach would look something like this:

public class UserService : IUserService
{
	private readonly Func<IUserStore> _userStoreFactory;

	public UserService(Func<IUserStore> userStoreFactory)
	{
		_userStoreFactory = userStoreFactory;
	}

	public async Task<string> GetNameAsync(int id)
	{
		return await _userStoreFactory().GetNameAsync(id);
	}
}

If the IUserStore implemented IDisposable and needed to release resources eagerly it would look more like this:

public class UserService : IUserService
{
	private readonly Func<Owned<IUserStore>> _userStoreFactory;

	public UserService(Func<Owned<IUserStore>> userStoreFactory)
	{
		_userStoreFactory = userStoreFactory;
	}

	public async Task<string> GetNameAsync(int id)
	{
		using (var userStore = _userStoreFactory().Value)
		{
			return await userStore.GetNameAsync(id);
		}		
	}
}

I would also configure and build your container outside of the factory delegate so you don’t accidentally apply the same pattern when working with other types of services (such as reliable actors) and end up creating multiple instances of the container. When you use the integration all your services (including the SF services) are registered up front before building the container so this wouldn't be an issue.

Hope that helps. 😃

from autofac.servicefabric.

Glad it is working well for you. Yes, the store and its dependencies will be created in their own lifetime scope that will be disposed at the end of the using, essentially making it instance per method call. 👍

from autofac.servicefabric.

I added some quick docs around the Service Fabric integration which includes this faux per-request info so hopefully it'll help folks in the future.

from autofac.servicefabric.

For information: microsoft/service-fabric-issues#269 (comment)

from autofac.servicefabric.

Absolutely perfect, thanks so much! This appears to be exactly what I was looking for. I had no idea AutoFac was this powerful. What a great piece of kit! I shall have a play with this in the coming days 😄

from autofac.servicefabric.

I've now implemented this and it works brilliantly.

I opted for

public class UserService : IUserService
{
	private readonly Func<Owned<IUserStore>> _userStoreFactory;

	public UserService(Func<Owned<IUserStore>> userStoreFactory)
	{
		_userStoreFactory = userStoreFactory;
	}

	public async Task<string> GetNameAsync(int id)
	{
		using (var userStore = _userStoreFactory())
		{
			return await userStore.Value.GetNameAsync(id);
		}		
	}
}

This way, correct me if I'm wrong, a new scope is created per method call. So any services which are registered as per scope (or transient) will be constructed and then destroyed at the end of this call - In this case the IUserDbContext. Seems to work as I wanted anyway, unless this is not a sensible thing to do?

from autofac.servicefabric.