Do you use auto-generated WCF service references in line of business applications? Or do you roll your own? And why?
EDIT
For anyone looking to roll their own, I found this article which may prove useful: Understanding WCF Services in Silverlight 2. There's another article on the site for Silverlight 3 which may be a useful addition: Understanding WCF Faults in Silverlight 3.
I typically roll my own, or tweak the ones generated by the auto-generated wizard.
I have two scenarios, most of the time:
I control both ends of the wire - in that case, I share the assembly with the service and data contracts between the service and client, and in that case, I write my own clients from scratch, as ClientBase<T> descendants or using a ChannelFactory<T>. Unfortunately, this is not an option with a Silverlight client, as far as I know :-(
I get WSDL+XSD from a third party - in that case, I typically use svcutil.exe to generate a first version of the client proxy, and then I tweak that to suit my needs (especially the configs generated by svcutil or VS "Add Service Reference" are horrendously bad.....)
I just like to have that extra control of doing it myself and totally knowing what's going on.
I haven't had to use Silverlight to access a service I didn't control, but in accessing a WCF service that I do control, yeah, I use the standard auto-generated WCF references. Rolling my own would just be too painful when the service is changing regularly.
If you control both ends of the service, you should also strongly investigate RIA Services, which implements a much more elegant way of keeping your Siverlight client in sync with your WCF service than having to manually regenerating your service references each time the interface changes.
Related
I've been handed a project that needs some work doing and the original team that created it have all since left the company. This has been sat "on-the-shelf" for 4 years and everyone but our client had forgotten about it. They want it delivering now and it doesn't work.
The system is a relatively simple ASP Web Forms application for submitting data to another service via 2 WSDL interfaces, logging that request in a SQL database and submitting the response to another service via OPC.
I can set up all of those interfaces for testing except the WSDL. I just have the software here to run. Is there any way I can easily create a service to simulate the final one so I can test my software. I only have the 2 WSDL files to go on. These aren't complicated services. I'm only using 4 methods total.
I've been led to believe that the original creator of this system did something similar but I can't find what he used or any documentation about it. I expect it was run on his laptop and was lost when he left the company.
The WCF service client should be wrapped and exposed via an interface to your software. That way, you can mock the interface and test how your software responds to various inputs/outputs from the mocked service client. You control all aspects of what is returned, including potentially throwing exceptions as the real WCF service client would.
This is basically the reason why the "I" in SOLID exists - because substitution of implementation based on interface is simple to do.
We currently have an application (Client/Server) that communicates through WCF. We would like to move away from the WCF approach and use a REST approach instead.
There are a few reasons for this, such as overhead (in terms of size) and the possibility to use the same access method for both our Windows client (currently a WinForm client) and mobile devices.
We are also sometimes running the server on the Mono framework, and even though we have it up and running, we have seen some differences regarding how WCF is working on the Mono stack compared to the .NET Framework (so I would not like to use the WebHTTPBinding in WCF to handle REST).
The service also needs to be self-hosted (i.e. not in IIS).
The problem when shifting from WCF to other alternatives is related to contracts. I would like to make it possible to unit test the REST calls, and I would like a contract to be involved, enabling the clients to use proxy classes that they do not have to create by themselves - pretty much like WSDL.
The main idea for handing out proxy classes to developers is that the clients should be able to rely on the service provider to get the correct proxy classes and that they should not need to care about the URLs used.
Is there any way this could be done automatically, and if so - using what framework or method?
Having looked brifely at WebAPI, I came across an example of generating a proxy (http://www.codeproject.com/Tips/535260/Proxy-Object-Generation-for-MVC-and-WebAPI-Control). This would simplify for the developers, but would mean that I manually need to create the proxy for the developers to use.
Any suggestions would be appreciated :)
For Client side unit tests, you should create mock for your rest service responses.
Otherwise You can create a static mock page with all of your service responses.
I hate MSDN's site for WCF RIA services. It does not say what it is, it only says what it does. It says what it can achieve but does not say why I need it.
For example:
"A common problem when developing an
n-tier RIA solution is coordinating
application logic between the middle
tier and the presentation tier".
Well, it does not mean much to me.
"RIA Services solves this problem by
providing framework components, tools,
and services that make the application
logic on the server available to the
RIA client without requiring you to
manually duplicate that programming
logic. You can create a RIA client
that is aware of business rules and
know that the client is automatically
updated with latest middle tier logic
every time that the solution is
re-compiled."
So does it download DLLs from server? Is it a metadata describing the rules for the data?
So what is it? Is it just a VS 2010 add-on for RAD? Or is it a technology on top of WCF or underneath it or what? Where does it live? With data, with server, what?
I appreciate if you can summarise this for me please.
RIA services is a server-side technology that automatically generates client-side (Silverlight) objects that take care of the communication with the server for you and provide client-side validation.
The main object inside a RIA service is a DomainService, usually a LinqToEntitiesDomainService that is connected to a LinqToEntities model.
The key thing to remember in RIA services is that it's mainly a sophisticated build trick. When you create a domain service and compile your solution, a client-side representation of your domain service is generated. This client-side representation has the same interface. Suppose you create a server-side domain service CustomerService with a method IQueryable<Customer> GetCustomersByCountry. When you build your solution, a class is generated inside your Silverlight project called CustomerContext that has a method GetCustomersByCountryQuery. You can now use this method on the client as if you were calling it on the server.
Updates, inserts and deletes follow a different pattern. When you create a domain service, you can indicate whether you want to enable editing. The corresponding methods for update/insert/delete are then generated in the server-side domain service. However, the client-side part doesn't have these methods. What you have on your CustomerContext is a method called SubmitChanges. So how does this work:
For updates, you simply update properties of existing customers (that you retrieved via GetCustomersByCountryQuery).
For inserts, you use CustomerContext.Customers.Add(new Customer(...) {...}).
For deletes, you use CustomerContext.Customers.Remove(someCustomer).
When you're done editing, you call CustomerContext.SubmitChanges().
As for validation, you can decorate your server-side objects with validation attributes from the System.ComponentModel.DataAnnotations namespace. Again, when you build your project, validation code is now automatically generated for the corresponding client-side objects.
I hope this explanation helps you a little further.
The latest news: WCF RIA Services is dead:
http://blogs.msmvps.com/deborahk/who-moved-my-cheese-ria-services/
If you want to use RIA Services, they have been open sourced:
http://www.openriaservices.net/blog/posts/
I have a solution that contains two projects (web services and client application).
When i built solution, i always need to update Web References manually (web service's proxies).
Is there any way to do it automatically with MSBuild?
You should be able to use svcutil.exe to create the proxy for you. You just have to get all the parameters right.
You could share contracts via a Contracts DLL if that makes sense for you from a design perspective (you'll be breaking loose coupling) and you have the tooling (the WCF wizards make it easier to do)
I'm trying to implement a WCF Service in my program , howevery I don't understand something:
According to the book "Programming WCF Services" , Juval Löwy 2007 O'Reilly Media,.
Appendix C. - WCF Coding Standard C2 - Essential :
1. Place service code in a class library and not in any hosting EXE.
I don't understand this, where should I put my code? all my class are defined in my form application , How should I call my classes of the winforms from the Class Library of the service.
Am I missing here something??
Thanks,
Eyal
I like to structure my WCF solutions like this:
YourProject.Contracts (class library)
Contains all the service, operations, fault, and data contracts. Can be shared between server and client in a pure .NET-to-.NET scenario
YourProject.Service (class library)
Contains the code to implement the services, and any support/helper methods needed to achieve this. Nothing else.
YourProject.ServiceHost (optional - can be Winforms, Console App, NT Service)
Contains service host(s) for debugging/testing, or possibly also for production.
This basically gives me the server-side of things.
On the client side:
YourClient.ClientProxies (class library)
I like to package my client proxies into a separate class library, so that they can be reused by multiple actual client apps. This can be done using svcutil or "Add Service Reference" and manually tweaking the resulting horrible app.config's, or by doing manual implementation of client proxies (when sharing the contracts assembly) using ClientBase<T> or ChannelFactory<T> constructs.
1-n actual clients (any type of app)
Will typically only reference the client proxies assembly, or maybe the contracts assembly, too, if it's being shared. This can be ASP.NET, WPF, Winforms, console app, other services - you name it.
That way; I have a nice and clean layout, I use it consistently over and over again, and I really think this has made my code cleaner and easier to maintain.
This was inspired by Miguel Castro's Extreme WCF screen cast on DotNet Rocks TV with Carl Franklin - highly recommended screen cast !
Yes, it's a bit confusing.
We're talking about the service implementation here. What Loewy means here is that the code to implement the service should be in a separate project. The code that hosts the WCF service (i.e. the class that implements your service contract) should do nothing but call that service implementation code.
So your Windows Forms client application uses a proxy, which in turn calls the WCF service application hosting layer, which in turn calls your service logic.
It's a very good idea to go further and have three layers on the UI side and four on the service side. The namespaces might be
Company.Project.UI.WinForms
Company.Project.UI
Company.Project.ServiceClient
Company.Project.ServiceHost
Company.Project.Service
Company.Project.BusinessLogic
Company.Project.Persistence
For simpler projects this would be overkill, but for anything more than (say) one form or two service methods it will make life much easier. Not least, testing each layer in isolation should be fairly straightforward.
Here's a typical project structure following Löwy's recommendation:
MyProject.Data
MyProject.Logic
MyProject.Services
MyProject.ServiceHosts
MyProject.Presentation
Then MyProject.ServiceHosts will reference MyProject.Services and exposes the services defined there. So in Löwy's language, MyProject.Services is the class library, and MyProject.ServiceHosts contains the hosting executable.