3-Tier Architecture and VAB

Topics: Validation Application Block
Oct 16, 2007 at 3:49 PM
I currently working on validated my web services using the VAB and WCF integration. It works fine when I am validating the web service calls using parameter inspection. Now, I want to reuse the validations that I have setup in my service tier in my client tier. The basic structure of my project is:

ServiceLayer (contains validation attributes on data contracts)
WebApplication

The web application calls the Service Layer threw proxies generated by svcutil. So, there are no direct references to the ServiceLayer assembly from the web application. My current though is to provid an operation that the clients can call to validate and object which returns a facade for ValidationResult(s). The downside of this is that you cannot use the PropertyProxyValidator (I would basically have to write my own that handle the mapping of controls to the web service's validation operation and its results).

Any suggestions would be appreciated.
Jan 16, 2008 at 11:10 PM
Hi, I'm in the same 3-Tier Architecture situation as ehauser. Can someone provide suggestion as to what is the best approach?

Thanks.
Mar 7, 2008 at 10:21 PM
Edited Mar 7, 2008 at 10:24 PM
Have you thought about using the NetDataContractSerializer instead of the normal DataContractSerializer? I believe the NetDataContractSerializer serializes the whole CLR datacontract type which i guess could be used to preserve validation information(?). You can find more information about how to use this serializer by typing svcutil /?

Downsides:
1) Must have exact type knowledge at client end (reference the servers datacontract assembly)
2) Less interop since this serializer basically restricts client to using .NET

We also have a SOA 3 tier architecture and we decided to attack this problem using a different angle. We decided to go for a 100% configuration based approach. We split up our validation config. information into a seperate "shared" .config file which we use the Entlib tool to configure our validation rules. The trick is allowing both the client and server apps to use the same config file which we have successfully implemented, albeit with a few hurdles to overcome.

This is our setup:

*Validation.Common.Config (this is where all validation config is maintained)
**Client app.config: references a Client.Entlib.Config file
**Server web.config: references a Server.Entlib.Config file

Now you may ask why doesnt the client and server config files reference our shared validation config directly? Well quite simply because the validation adds fully qualified type names into the config for the types that you wish to validate. And these are not compatible (the server has the actual datacontract types, the client has the proxy types). Fortunally they are placed in the same namespace by the svcutil so its basically only the assembly location that differs. We solved this by running a small script everytime we build our aps that replaces the type references with the correct assembly location depending on whether its the server or client being built.

This might sound a bit complicated but trust me it is not. And once it is up and running we have really saved a lot of time and gained a helluva lot of consistency between our client/server as far as validation goes!