Models and Validation in Multiple UI Delivery Mechanisms

Question

I work with a small team. We have multiple delivery mechanisms, often for the same business models but different exposures. We need some help with our efficiencies sharing models and validation across our applications.

What is the best mechanism to create consistent validation for our models, for both user experience and code reuse across Silverlight 3 (non-RIA Services), ASP.net MVC, and WPF?

We are open to using EF, NHibernate, or Linq to Sql for our domain models. Creating DTOs and Presentation/View Models is acceptible as well.

The unfortunate part is that the database is legacy and does not follow good conventions for keys.

We would like to build a single set of models,and validation (simple validation) visitors or such that can easily be used across all the delivery mechanisms. The MVP or MVVM pattern looks appealing as well as UpdateControls, but I have been unable to find a single pattern that seems to work across all mechanisms.

The removal of ComponentModel from Silverlight 3 seems to invalidate most of the examples on the web.

Any advice would be greatly appreciated.

Answer 1

Well I would personally op for Plain Old ClR Objects POCO for the business model.

using System.ComponentModel.DataAnnotations;

The above namespace brings validation to your objects also. There is the Enterprise Application Validation Block but I have not known a way to integrate this into Silverlight client side.

But the benefit is you could create your business model and decorate with the DataAnnotations and then re-use this business model across.

It would fit straight out of the box with NHibernate, but not EF as this does not allow for POCO. Linq-to_Sql does I believe but you would need to either use mapping files using SQL Metal or specific meta data fro Linq-To_Sql.

One of the problems, well not problems but rather scenarios I have come across is that I use WCF to commmunicate between Silverlight and the server. This gives you a Generated code base for the service, and altering this means any changes will be lost next time you update the service.

The use of the MetaDataType is something also which I would love to see available inside Silverlight as it means you can decorate the generated classes without risk of losing your work upon regeneration.

If you are working .NET to .NET on the WCF you gain greater functionality of course but if you need the validation and return of errors to be interoperable, I have a base Response class which contains HasErrors and Error[] properties. I am currently doing the following:

Silverlight: - Generated WCF Service Proxy - A ViewModel which wraps the Service Proxy Classes intercepting the setters and getters - Applying client side validation using the System.ComponentModel.DataAnnotations

Business Model: - I am using POCO with NHibernate - I am using the Enterprise Application Validation Block - I have a base Domain Class with a HasErrors and Errors properties

WCF: - I am using DTOs using a Request and Response i.e.

AddClientResponse AddClient(AddClientRequest request)

Silverlight consumes the WCF Service whilst WCF Services consumes a repository which uses the Business and Data Access layer.

With the above I can roll out with say a flex client, and if I do not handle data validation on the Flex client side, the client will still receieve errors back in the base response class. It then needs to do client side validation or handle the errors returned from the server. Client side ofcourse saves the roundtrip.

[DataContract]
public class BaseResponse
{
    [DataMember]
    public Error[] Errors { get; set; }
    [DataMember]
    public Boolean HasErrors { get; set; }
}

Hope this helps!

I am on the knowledge quest myself as always lol :-)

Andrew