It looks interesting. There are some specific problems I'd like to see solved though. Most serious is below:

A big pain we have at the moment is keeping knowledge in as few places as possible in order to make maintenance easier and creation easier. Knowledge that most suffers are things like data types. Knowledge that this field is a date or a string limited to 32 upper case characters that cannot take blanks. Maybe even things such as more complex validation, a regular expression match, an email address.

At the moment that knowledge has to be coded into every form or field that the data appears in. It's easy for the programmer to forget - what's a missing property between people? - and if you change it it's easy to miss places where it's used. Also in Dot-Net-2 it seems hard to get basic support for this type information to go into things like DataGridView. I bind to a Date and I get a Text Box Editor that lets me enter non-date characters. The Cancel action in the Validating event is not user friendly and seems to give no chance for good feedback - or I'm getting it wrong.

An entity model seems like a wonderful thing to get this knowledge coded in the one place where it is really known - the conceptual model of the system. If that model carries through the code then it should be possible that when you bind to it the knowledge is used. The form controls should automatically pick up types validation, and ideally there should be an easy to use mechanism for inserting more complec business validation into the model.

I know this gets into arguments we've seen in the modelling world of where the business logic belongs - intelligent model or intelligent middle tier. Some things though are so basic they should be there in the model. There are there in the model when it hits the database. It should be easy to carry this to the front end and the user.

 - Richard