Ok so I have built my WCF service and its functioning great! However, I am starting to implement it into our pre-existing piece of software now and I am instantly running into the question, do I only use the proxy generated code and get rid of the dll that I used initially? Or do I keep both, and make distinctions between the two very obvious?
What I mean by keeping distinctions is, having a ServerUser and a LocalUser property that represent the same user object. However, my LocalUser property would be filled via the dll that the app initally ran with, if the application service is unavailable.
My main reasoning for this thought pattern is that if I remove my dll, I have a single point of failure. If for some reason my ServiceHost is just not up and running, but the DB server is, I would want my users to still be able to do their job. The features that the new WCF implementation utilize are not dependant for employees to do their job. It is more of a convenience in what the WCF service provides. Also, building in this kind of logic to the Service would allow service modifications more readily available in a non IIS hosted environment.
Also, is there a way to build in logic on the service so that when I pull down the proxy code for the client that it just knows to access the DB manually if the ServiceHost is unavailable? If this was a possibility, I think about 90% of all my problems would disappear.
Thank you in advance!
From what you describe it sounds like keeping your existing DLL, i.e. direct access to the DB, would best suit your needs. Having a WCF service adds nothing if, when it fails, you'll just use the DLL anyway.
Ideally you would go with the WCF service completly and offer some kind of redundency to deal with any potenial service issues. Plus, using a service will mean you won't have to deal with any DLL upgrades/deployments.
But, from your question, it sounds like there would be some real issues to deal with should the service not be available, so just do with the DLL.
EDIT: Just read the last part of your question and I don't think that is possible. The proxy code for accessing services is generated when you add the reference to your project. The kind of "dynamic" information you're after would actually require a service.
EDIT: As a follow up to my comment below you could test this by creating a DLL and class, lets call it Class1. Then create a WCF service with a method that will return Class1. Create a client application and add a reference to the service. If you look at the proxy-generated code you should see (hopefully...I'm thinking of this as I type :)) that the method returns Class1, but when you compile it won't be able to find Class1. This is because Class1 does not have the DataContractAttribute which would auto-generate Class1 on the client. So, you have to distribute the shared DLL to the client. Now when the method returns and WCF tries to re-create Class1 it will use the local version in the shared DLL. Your other DLL, which will already be on the client, would use the same shared DLL.
Related
I could have sworn I saw this done somewhere, but I guess maybe it was a DLL, not a web service. I was originally doing this as a DLL, but now need to use a web service.
I have a service file (DataService.svc). I have class Foo and class Bar. Both have the same methods (Load, LoadAll, Insert, Update). I know that a web service doesn't support overloading, but I thought that since these were in separate classes it might be possible. Is there a way to configure this so that in my client, I could do this:
DataService.Foo.Load();
or
DataService.Bar.Load();
Thanks,
Andrew
I have quite simple WCF service and its client - both reside in my application.
At the moment interface used for WCF contract consist of 3 methods, and according to MSDN I generated client code for it using svcutil.exe CLI.
But now I added one more method. And I wonder - is there a simpler way to regenerate client code (probably directly in VisualStudio) using doing less actions for this operation?
Right click on your Services References and select the service you'd like to regenerate code for. Then click Update Service Reference. Then you're done.
Update after re-reading the question I realized its possible you don't know how to import WCF Services.
Here is how its done:
Update as per comments:
There are two workarounds for this, The first is to run the application outside of your IDE and then go into your IDE to import it.
The second one is to create a proxy client that implements your service contract. When you are using the client proxy you can right click on the interface and select an option to implement the interface. Assuming that the set up is done correctly, if you make a change to the ServiceContract you can then go to your proxy class and just click implement interface which will update your proxy class. by doing this you bypass the svc utility completely; however, you have significantly more control over your development. You need to work with DLLs to accomplish this; however, it works like a charm. Here is an example though I doubt you need one I'll just leave it for the sake of completeness. Use this example for duplexes
I have two projects in the same solution, a service and a consumer app. In the service I have many classes that can be instantiated by the consumer app but some classes are not accessible. There's no difference apart from name. All classes are all Public so they should all be seen. Is there any buffering problems or anything else that could cause the problem to behave like this?
Consumer does not get access to Server classes when you use WCF or any other Web Services/Removing technology. Proxy classes are created instead. Think about them as set of Interfaces that are able to call method over app boundaries. You can instantiate proxy classes but when you call method proxy class will go to Service and call corresponding method of class hosted by service.
You need to use Class Library and move move your shared classes there (and deploy dll with Service and Consumer) if both parties use them.
Update (thanks razlebe):
Business logic should not be shared in DLLs. It should be hosted by server. But it will make sense to share supporting classes (for example class that do data formatting) to avoid code duplication.
When you update service class and change interface by:
Adding a method (Your case)
Removing a method
Changing signature
Your consumer needs to learn about the change. You have to update service reference (http://msdn.microsoft.com/en-us/library/bb628652.aspx) to rebuild proxy.
How to update it?
Check here to see how: http://msdn.microsoft.com/en-us/library/bb628652.aspx)
But one image is better than thousand words:
My guess is that the classes that "are not accessible" were created after the last generation of the proxy (classes of the service, client-side). Check if REgenerating the proxy helps.
looking at
WCF ChannelFactory vs generating proxy
appears that the best practice in creating a WCF client is to create a proxy (Not autogenerated).
I've been looking online for a while and i didn't find any complete example(Proxy class, web.config)
Could you provide an example or links to resources?
This article is about exactly what you're asking, I believe:
WCF the Manual Way... The Right Way
Having shared that, though, creating your proxies manually is probably not always the best possible use of your time. The article goes into some great reasons for doing so - you'll certainly have more control, your clients may have an easier time, etc. but overall, doing things manually like this will require more of your time, and explaining to users of your service exactly how to use the proxy you provide may be a pain.
There's a reason WCF allows metadata exchange and discovery and VS will auto create proxies for you.
Either way, it's a cool article and a technique well worth learning.
This is how I do it.
Get service contracts and data contracts
If I have access to the service code, I have all the contracts. If not, I can use svcutil or Add Service Reference to generate them.
Make config
I use Add Service Reference just to get the app.config file. I then delete everything else it generates. Edit the app.config as necessary.
Define factory
Say I have a service contract IFooService:
interface IFooServiceChannel : IFooService, IClientChannel { }
That is literally it. No members.
Create factory
fooServiceFactory = new ChannelFactory<IFooServiceChannel>(
"NetTcpBinding_IFooService");
The string "NetTcpBinding_IFooService" is the name attribute of the binding element in app.config.
Create channel
fooService = fooServiceFactory.CreateChannel();
Use it
fooService.DoSomething();
The trickiest part is getting app.config right. You need to learn about bindings and endpoints. It's a bit of a learning curve, but nothing drastic.
Here are the basic steps.
Create your service like normal.
Move the interface that your service implements into an assembly that can be shared with the client.
Create a ChannelFactory where T is your interface. You will have to give the uri of your service to the constructor.
Call factory.CreateChannel(). This will be type T.
Use the channel to make calls.
It is really that simple. No auto generated code, no service references. It gets a little more complicated with async calls and Silverlight, but not too much.
I have description of my Application Services using my fancy classes (ServiceDescription class that contains collection of ServiceMethod description, for simplification).
Now, I want to expose one Application Service as one WCF Service (one Contract). The current solution is very lame - I have console application that generates *.svc file for each Application Service (ServiceDescription). There is one method (Operation) generated for one ServiceMethod.
This works well but I would like to make it better. It could be improved using T4 template but I'm sure that there is still better way in WCF.
I would still like to have one *.svc file per one Application Service but I don't want to generate methods (for corresponding Application Service methods).
I'm sure that there must be some interfaces that allow to discover operations dynamically, at runtime. Maybe IContractBehavior...
Thanks.
EDIT1:
I don't want to use generic operation contract because I would like to have the ability to generate service proxy with all operations.
I'm sure that if I write WCF service and operations by hand then WCF uses reflection to discover the operations in the service.
Now, I would like to customize this point in order not to use reflection, just use my "operations discovering code" instead.
I think there is nothing wrong with static code generation in that case. In my opinion, it is a better solution than dynamic generation of contracts. Keep in mind that your contract is the only evidence you have/provide that a service is hosting a particular set operations.
The main issue I see about the dynamic approach is about versioning and compatibility. If everything is dynamically generated, you may end up transparently pushing breaking changes into the system and create some problems with existing clients.
If you have a code generator when you plan on implementing some changes in the application services, it will be easier to remember that the changes you make on the services may have a huge impact.
But if you really want to dynamically handle messages, you could use a generic operation contract (with the Action property set to *), and manually route the messages to the application services.
Keep in mind that you would lose the ability to generate from the service a proxy containing a list of operations available.