ALFKI

Hello,

I'd like to know how you handle business logic such as data validation that should execute on the client, in a scenario where the core domain layer remains on the server and clients communicate with it using simple data-transfer objects. The DTOs are just simple data holders with no logic in them, so it would be a code duplication error to re-implement validation logic in them that normally is in the core domain classes. So when the client attempts to set a property in a DTO with invalid data, it is not validated until it gets back to the server where it's data is extracted and put into core domain classes. Ideally, though, we would like to catch this error on the client and provide instant notification before the DTO is submitted to the server.

Any ideas welcome...

Thanks



Re: Architecture General Remoting DTOs and client-side business logic

VikasGoyal

Hi .. i am not sure about your app architecture but at client layer you can always have validation utility classes where you can do data type/size kind of validations. e.g. while implementing MVC patterns for web applications , command classes do the basic validation before submitting the DTOs to business logic.

http://DotNetWithMe.blogspot.com
vikas goyal






Re: Architecture General Remoting DTOs and client-side business logic

Ed Hill

Hi ALFKI

You have to be careful not to leak business logic onto the client.

If, howerver, you mean simple data validation such as type, length, range validation then it's perfectly acceptable to have client side checks for this as well. The sort of checks you could easily add if you had an XSD defined for an XML representation of the DTO is a good rule of thumb for deciding what's a simple check.

It seems like a pain to check this in two places but DTO's are independant of the domain model:

Looking at Martin Fowlers example:

http://www.martinfowler.com/eaaCatalog/dataTransferObject.html

The DTO has no field called name, it's called artist. This could be further complicated by the DTO artist field being a concatenation of the artists first and last names which might be seperate in the domain model.

I would suggest looking into utility validation code that allows you to specify this simple validation using attributes on the set methods of your DTO's. I've used this method quite effectively before and as it's a utility class you can use it to decorate the domain model as well, this also has the added benefit of clearing out a lot of basic validation code from within the domain model methods which allows the reader/writer to concentrate on the more important 'business' logic.

I'd be surprised if the Enterprise Validation Library doesn't support attributes:
http://davidhayden.com/blog/dave/archive/2006/11/27/EnterpriseLibraryValidationApplicationBlock.aspx

Regards

Ed Hill