within our per-session WCF services hosted in ISS, we would like to use Ninject to IOC different data access component through the interface.
Where would be the best place to declare the binding once? is it in Application_Start of Global.asax?
If it is, how could I obtain the instance through the inferface from Ninject?
I know in StructureMap, we can call something like ObjectFactory.GetInstance()?
What is the equivalent in Ninject?
Thanks
I assume you have looked at the official WCF extension? I usually define my own service factory (referenced in the .SVC file) and reference my Ninject module from there.
As for getting an instance from an interface (i.e. the opposite of having it injected), you do so via the kernel. (You can always have an instance of IKernel injected into any of your classes by adding it to your constructor.) Once you have it, you just use:
kernel.Get<IYourInterface>();
Related
Just want to confirm my understanding is correct. If I use Single instance mode for a service:
[ServiceBehavior(InstanceContextMode=InstanceContextMode.Single)]
and this service calls a class from another asssembly which has a static constructor, that constructor is only called the first time ther service is called? The constructor I am talking about sets up a fair number of AutoMapper maps, and I only want this overhead the first time the service is called.
Taking this further, If I have two different services, and they both us the shared class, am I correct that the static constructor is still only called once?
Best
Ray
There is no connection between InstanceContextMode and how many times static constructor is fired. Static constructor is called once per Application Domain. So if your services are hosted within one Application Domain then your constructor will be called once.
As far as I understand you use the contructor to register AutoMapper configuration... To me it is not a good approach. Assuming your services are hosted on IIS you would better create a Global.asax file and then run you mapping registration code in Application_Start method. Of cource you can wrap it in some static method first.
Hope it helps!
I have a WCF service and need to register my interfaces and my classes with structuremap, in a regular asp.net application I would do it in global.cs in onApplicationstartup since this is called before anything else, but where do I initialize my structuremap in a webservice?
You have multiple options:
Put your Structuremap code in a static variable that is initialized on first access
Use a custom ServiceHostFactory which initializes the library before creating a ServiceHost.
Create a custom WCF ServiceBehavior which does the initialization, and apply that to all relevant services inside the ServiceLibrary.
I have a wcf service singleton type, and in the same application an ASP page that uses a service-specific function.
As I can get a reference to the service instance created, not to run twice the manufacturer's service?
My service is published on IIS
I'm guessing you are saying that you have a service that is supposed to be a singleton and because you're in the same AppDomain you can simply create an instance as well.
If you own the service code you can make it a singleton using the Singleton Pattern (there are a number of ways to do that in .NET and Jon Skeet has a list of them here).
Then you need to deal with how does WCF get hold of the instance? In that case there are two options:
Use a ServiceHostFactory and hand the instance to the ServiceHost you create
Implement IInstanceProvider and plumb that in
If you don't control the service class then there is nothing you can do to prevent people creating instances but you can wrap the class in your own singleton and stipulate access must only be via the singleton so it is less likely that someone will create a second instance
I'm trying to hock up WCF with dependency injection. All the examples that I have found is based on the assumptions that you either uses a .svc (ServiceHostFactory) service or uses app.config to configure the container. Other examples is also based on that the container is passed around to the classes.
I would like a solution where the container is not passed around (not tightly coupled to Unity). Where I don't uses a config file to configure the container and where I use self-hosted services.
The problem is - as I see it - that the ServiceHost is taking the type of the service implementation as a parameter so what different does it do to use the InstanceProvider?
The solution I have come up with at the moment is to register the ServiceHost (or a specialization) an register a Type with a name ( e.g. container.RegisterInstance<Type>("ServiceName", typeof(Service);).
And then container.RegisterType<UnityServiceHost>(new InjectionConstructor(new ResolvedParameter<Type>("ServiceName"))); to register the ServiceHost.
Any better solutions out there? I'm I perhaps way of in my assumptions.
Best regards,
Michael
Use Constructor Injection to wire up your service implementation, just like you would with any other class.
Here's a writeup on how to make WCF understand Constructor Injection.
The example in that answer demonstrates Poor Man's Injection, but you can extrapolate from it and set up your UnityContainer instance in the ServiceHostFactory instead of a hard-coded dependency.
You pass the container instance all the way to the custom IInstanceProvider. Now you can use the container in the GetInstance method:
public object GetInstance(InstanceContext instanceContext)
{
var serviceType = instanceContext.Host.Description.ServiceType;
return this.container.Resolve(serviceType);
}
I am hosting a service within a Windows Service.
The following snippet instantiates the ServiceHost object:
Host = new ServiceHost(typeof(Services.DocumentInfoService));
The DocumentInfoService class implements a contract interface that has methods that invoke business objects requiring initialization (actually a connection string). Ideally, I'd like the hosting process to get the connection string from the config file and pass it to a constructor for my service object, DocumentInfoService, which would hold onto it and use it to pass to business objects as needed.
However, the ServiceHost constructor takes a System.Type object -- so instances of DocumentInfoService are created via the default constructor. I did note that there is another constructor method for ServiceHost that takes an object instance -- but the docs indicate that is for use with singletons.
Is there a way for me to get to my object after it is constructed so that I can pass it some initialization data?
ServiceHost will create the service instances based on the binding and behaviors configured for the endpoint. There's no particular point in time, where you can rely there is a service instance. Hence, ServiceHost does not expose the service instances.
What you could do is add code to your service object constructor to read the relevant configuration values itself through the ConfigurationManager class.
Of course, if you don't keep your configuration in the app.config, that won't work for you. Alternative approach would be to have a well-known singleton object that the service instances access when created to get the necessary configuration.
And there's also the option of creating your own ServiceHost or your own ServiceHostFactory to control the service instantiation explicitly. This would give you acess to the new service instances at the moment of creation. I would stay away from that option though. It's not worth the effort for your scenario.
Implement your own ServiceHost. See also http://hyperthink.net/blog/servicehostfactory-vs-servicehostfactorybase/