If I have a client/server type of application built using both Prism and WCF, and I would like on the serverside to have the wcf service to be instatiated per call BUT I would like to use dependency injection (using the UnityContainer in Prism). How could I possibly do this? Should I have a single instance service it would be no problem, but are there any hooks in WCF to allow for a delegate to be called whenever a service is supposed to be instantiated and have this instance returned?
Any ideas?
Cheers!
It is possible! WCF provides a plugin to the WCF responsibility chain called an IInstanceProvider. This allows for you to replace the construction with your own.
Someone has implemented this as a service behavior and is available here:
http://code.msdn.microsoft.com/WCFResources/Release/ProjectReleases.aspx?ReleaseId=1252
Related
I would like my ASP.NET Core application to send messages to a Azure Service Bus.
In Microsoft's article Best Practices for performance improvements using Service Bus Messaging they argue that you should re-use instances of clients.
It is recommended that you do not close messaging factories or queue, topic, and subscription clients after you send a message, and then re-create them when you send the next message.
So I take that as I should not instantiate a new instance of the client (TopicClient or QueueClient) inside my controller using the new keyword.
I guess that I should use dependency injection in ASP.NET Core.
Should I directly inject a TopicClient/QueueClient or should I create an own class that wraps an instance of the client and expose a SendAsync method?
When registering the service with dependency injector should I register it as a singleton?
We did it with a wrapper class that is then returning the TopicClient/QueueClient and registered it as a singleton and found no big issues with this approach.
We based our approach on this example provided by Microsoft eshopOnContainers.
The example code for this functionality is found in this file. They than register this class as singleton in Startup.cs in the services where they require ServiceBus.
My issue it regarding creating a dummy WCF service which can be used at development side, when the REAL WCF service is not available or is down.
In my current assignment, the issue is that the web hosted WCF service from client is not always available for developer side. This hampers the development work as we are not able to verify/unit test the client side code.
Any solutions in sight? I have been searching /reading about mocking wcf with different available mocking frameworks, but still not clear about the right way.
Thanks in advance !
Without talking about frameworks - to call your srevice, you create client (proxy) instance, right?
You can move its generation to separate method, which will return your mock (injected by DI, injected by setter property in Unit test,. . .).
Where is the best place to put code for when a WCF service is just started up? Similar to Page_Load in a web application.
The service implementation constructor would be the obvious place but it also depends on your hosting model
1) run once code: IIS hosting = global.asax; self-hosting = Main / OnStart
2) run once per service instance: constructor of service class
3) Something more exotic: implement IInstanceProvider
In the class constructor of the service implementation.
Honestly the best place is the constructor and/or static constructor for your service class (for static members). There is no other WCF specific lifecycle event that will notify your service implementation when it's being created by the service host.
Now, if you're talking about the creation of services generically, that would mean you're willing to hook into the WCF runtime and there you can do things like get in the middle of the instance creation with a custom IInstanceProvider implementation.
So I already have a working implementation of StructureMap with the WCF service (including custom instance provider, behaviors, etc.)
When I try to have an object that is instantiated only once per user request, I use the InstanceScope.HttpContext and it throws because the context is null.
Do anyone have a proper way of doing that?
On the server-side of the WCF service? By default, WCF has nothing to do with ASP.NET and thus all your HttpContext etc. aren't there.
By default, your WCF services will be called on a "per-call" basis, e.g. each request gets a brand-new, separate, totally isolated instance of your service class. Why not just put those things into the service class as internal fields??
Or you might want to check out this blog post on how to abstract request state and providing sample implementations for ASP.NET (using HttpContext.Items) and WCF.
I have an existing WCF service.
Is it possible to add operation contract to the service interface and have the implementation in a workflow?
Or I absolutly need a seperate service interface for my workflow?
When you publish a WCF service you are publishing the interface and telling it what implementation to use. You can specify only one implementation, otherwise how would WCF know where to route which request. So in short you need to use a separate interface for your workflow services. That said, if you don't want to change your public facing API there is no reason you can't create a minimal implementation that just passes request on to your worklflow service.