Url: http://niagara.codeplex.com

The goal of Project Niagara is to democratize the validation support. The project wants to help developers add validation support to ADO.NET Data Services as well as Web Services in Silverlight. In addition, it has the goal of allowing multiple ways to supply the validation metadata to the different data access strategies. As it is my opinion that there are scenarios where attributes are not the best idea.

The deliverables for this project will include:

• ValidatingDataSvcUtil: Produce Validating Data Service Proxies.
• ValidatingProxy Library: Supply external metadata for generation of Proxies.
• MValidation: DSL for defining Validation outside of attributes.
• Oslo Integration: to store/retrieve validation out of the Oslo Repository.
• Alignment: RIA Services’ and ADO.NET Data Services’ Validation Logic

At this point the project is very young (version 0.1) and a lot of the pieces are not ready but I am looking for help!  I can’t write it all. Please visit the CodePlex site and take a look at what I want to accomplish and send me a message if you want to help out:

http://niagara.codeplex.com

Current State of Niagara

Currently, I have built up some infrastructure to allow the whole project. This inlcudes a first pass at the DSL.  The one working pieces is the ValidatingDataServiceUtil which allows you to manually generate (via the command-line) an ADO.NET Data Service proxy that includes support for validation attributes and calling validation during two-way binding.

The current version does not have a release yet, but if you’re brave and willing to report bugs, you can get the source and build it yourself.

To use the ValidatingDataServiceUtil, you can call it from the command-line:

NiagaraDataServiceUtil.exe http://localhost:14000/GameService.svc 
  ..\Niagara.Sample.Web\bin\Niagara.Sample.Web.dll 
  .\GameService.cs 
  Niagara.Sample.Data /v /b /c:V2

While more complex than the original DataSvcUtil, the arguments are pretty straightforward:

• URI to the ADO.NET Data Service endpoint.
• Path to the assembly that holds the types and metadata (so we can read the metadata with reflection).
• The output file.
• The namespace to use.
• Options to specify what version of the data service library to use, bindability and validation.

This is an alternative to using a service reference. We hope to move this to be a project item instead of a command-line for the project.

NOTE: It requires the ADO.NET Data Services CTP2 to work.

Let me know what you think!