Benefits of Business Entities in the client (WCSF with WSSF)

Topics: Web Client Software Factory, UIP Application Block discussion
Jul 30, 2007 at 11:37 AM
Hi,

We are developing an application with a web service back end (WSSF) and a Web Client front end (WCSF). There are a number of modules being developed which all hook into a number of web services.

What we have currently is the Web Service references in all the modules and also the development website. When a change occurs to the web services (this happens all the time) we need to update all the references. As well as this we need to use the wire types from the service proxies throughout the application, so whenever the service changes we need to go and refactor a fair bit of code (normally other peoples code) just to get the client building. Not to mention the wire type lists are arrays so we don't get the tidyness of generic lists etc.

The other factor is validation. This could be done in the controllers, but personally I find this messy. The team lead and other developers believe that all validation should be handled by a webservice, and as I'm only a freelancer then who am I to argue. As I am an OO developer by nature I would normally create a business object library that would handle all the validation, authorisation, and data retrieval from the services. In this way the controllers would merely create the objects and pass them to the presenters. The team here think that's adding unnecessary complexity, so maybe I'm fighting a losing battle. I am fairly new to web development and these factories so would appreciate any insight into how other people have created applications in this way.

Any comments would be very welcome.

Thanks, Dave.

Jul 30, 2007 at 3:47 PM
The Validation Application Block would be a good place to look for Validation. If you are using objects from a service proxy in your application then it would be easy to add config file set of validation rules for those proxy objects. Rather than translating to other objects just to provide validation. Also look at the PropertyProxyValidator for asp.net control validation, they are very useful. If using WCF for your WSSF then the same types of validation rules can be used and validated using the ValidationBehavior attribute on the service contract. Also if using WCF there are several documented ways to achieve backwards compatibility / versioning of your service contracts to avoid the numerous build errors that occur every time changes happen. Hopefully that helps.
Jul 30, 2007 at 3:59 PM
It sounds like you would be better off not referencing the web services in each module and the website, but instead working with a service contract in each module and the website. Then in a Foundation Module ( global service ), define the implementation of that service contract such that only it references the web service. Thus, when your web service changes, you only need to update the Foundation Module. This makes sense from a testing perspective anyway, because you will want to mock or stubb out the web services so you can unit test the client portion separate from the actual web services. This also helps you develop the modules separately from the services they consume in a team environment.

The web services will definitely need to do their own validation, because you can't assume that they will only be used by this web client. Every component, object, or service in the application is responsible for validating its input, however, so proper validation will be used throughout the application. This is criticial for finding bugs when they happen and not when they have been erroneously propogated through several components and layers. The Validation Application Block in Enterprise Library may definitely help you here and avoid having to create your own validation library. It makes it easy for you to do validation in several spots in your application. You would definitely want to validate what should be validated before going to the web service, because web services can be slow and you hate to needlessly call an out-of-process service just to have it tell you something is invalid for what you should have already tested.

Hopefully you are using WCF, because it was built with these kinds of applications in mind and works well.

I hope this helps.

Dave

_______________________________

David Hayden
Microsoft MVP C#
Jul 30, 2007 at 5:05 PM
Edited Sep 1, 2007 at 11:13 PM

I agree with David, you should definitely create a foundational services/proxy module to encapsulate all of your remote services. We even take this a step further and create wrapper classes for the services in the foundational module and then expose their interfaces to the business modules for injection. This allows the business modules to only have service references to the local foundational module. It also gives us a spot to clean up/dispose of our WCF services, since the implementation in our case lives on the app server, and also makes them super easy to mock for testing.

If you are doing WCF services in a ‘closed environment’, consider not using service references but the ChannelFactory<T>. This will save you from having to regenerate your references every time something changes.
http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=583401&SiteID=1

Guy Bernstein posted on his blog a while back a nice GenericProxy<T>, which uses the ClientBase<T> and a simple endpoint definition.
http://blogs.microsoft.co.il/blogs/bursteg/archive/2006/04/17/103.aspx

Using this method with WCF there aren’t any wire types, but DataContracts which are defined in a global assembly and referenced by both client and server. You get a lot more type information, such as interface implementations, generic lists, methods, events, etc (of course only serializing the data fields) and they never need to be ‘updated’ from reference. I haven’t attempted validation yet, but I plan on the rules going right on these domain objects as well, callable both on the client and server. Again, this is only usable in a closed app-server environment.

This is currently what we are using with WCSF and it rocks. We are still thinking about the client side model and any translation requirements each business module may have, (im hoping to get away with very little translation if any) but the reference challenge is tamed.

Jarod Ferguson
Jul 30, 2007 at 5:40 PM
I also agree with David on the Foundational Module. Sometimes I forget to mention those things that become almost automatic after using WCSF.