Skip to content
This repository was archived by the owner on Nov 2, 2018. It is now read-only.

Adding support for service factories in IServiceDescriptor #102

Closed
wants to merge 3 commits into from

Conversation

pranavkm
Copy link
Contributor

Fixes #64

@pranavkm
Copy link
Contributor Author

@loudej it doesn't look like Autofac has a way to get to the activation stack without private reflection or by intercepting all calls for activation and then looking at individual parameters to see if any of them match our factory. The latter might work, but I imagine it might affect perf.

I thought it made sense to not have DependeeType if we can't make it work everywhere. Thoughts?

@@ -13,5 +13,10 @@ public class ServiceDescriptor : IServiceDescriptor
// Exactly one of the two following properties should be set
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This comment should be updated.

In fact, I think it would be even better to make these properties to be be getters only. Then we could have three constructors. This would give a compile time guarantee that only one of these three properties can ever be set if the ServiceDescriptor type is used.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Fixed

@victorhurdugaci
Copy link
Contributor

@pranavkm As discussed offline, this change requires a few extension methods for IServiceCollection because when you call IApplicationBuilder.UseServices you don't have access to the underlying service descriptor.

@divega
Copy link

divega commented Oct 3, 2014

@pranavkm Is this going to be checked in any time soon? We want to use it in EF in this milestone.

@pranavkm
Copy link
Contributor Author

pranavkm commented Oct 4, 2014

@halter73 sorry I hadn't noticed your comments earlier. Updated the PR.

@pranavkm
Copy link
Contributor Author

pranavkm commented Oct 4, 2014

@divega I'll work on getting this in by next week.

/// <param name="serviceType">The <see cref="Type"/> of the service.</param>
/// <param name="instance">The instance implementing the service.</param>
/// <param name="lifecycle">The <see cref="LifecycleKind"/> of the service.</param>
public ServiceDescriptor(Type serviceType, object instance, LifecycleKind lifecycle)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LifecycleKind.Singleton should be the only option if you are providing an instance.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

👍

@pranavkm
Copy link
Contributor Author

pranavkm commented Oct 8, 2014

Updated

{
implementationType = Type.GetType(implementationTypeName);
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Type.GetType does not throw if the type cannot be found and simply returns null.

@halter73
Copy link
Member

halter73 commented Oct 9, 2014

You might want to talk to @lodejard before merging this so you two can decide how to reconcile these changes with the work he is doing in his feature-getservice-can-return branch.

Otherwise you got a :shipit: from me.

@pranavkm pranavkm closed this Oct 9, 2014
@pranavkm pranavkm deleted the Factory branch October 9, 2014 01:55
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants