Karl - great idea in keeping it close to a blank canvas... I checked out the code and for me it does make it easier to learn the patterns you are espousing.  Timely too... I've been looking for good repository examples using Fluent NH.  Thanks.

Karl, I've just taken a few minutes to look at your project so please forgive me if I'm missing something but I don't see how your using the IValidate interface.  In your other example the User entity inherited directly from it but that is not the case here.

I'm I missing something obvious?

Hi

I would like to see and use your project. I've never worked with google code so I could download your project to my computer?

Thanks

Hi Karl

I managed to install TortoiseSVN, thanks for the tip. Is there any documentation on how to use your project or just to understand it? I'm working on a project that I want to put in MVC and I'm in need of some guidance and some good patterns that, I think, your project will provide.

Thanks in advance

Hi Karl,

Have you thought about working in an implementation of the ViewModel pattern into the Canvas.  I would love to see a working example on how to handle mapping validations that are assigned as attributes to your model to a viewmodel for a specific controller.

Regards,

Roberto.-

@Karl,

What I meant was, how would you deal with validation when you have a ViewModel pattern in place?  

Context:

I assume that we can call your Credential, and User entities the Model, in most sample apps I have seen recently the Model's don't get pushed out to the View there is always a middle man the ViewModel that represents the specific data that your View needs.  In the Canvas the attributes for validation are assigned to the model and I agree that this is the right place for them but if we follow the ViewModel pattern those attributes would not be accesible to the View.

I assume that we can write a property in our ViewModel that would translate/expose the validation rules in the Model to the ViewModel.

Regards,

Roberto.-

would reside in a model (Its definitely where they should be), but the UI sees a ViewModel that is a buddy object that is

Oops.. plese disregard the last line of that comment! Apparently it needed some additional editing.

@Roberto @Karl

My current solution, and this is very early days, is to copy the rules from the domain model to the view (or in our case REST contract) model. The way we're doing it is essentially 3 steps:

1) Take the information that specifies how to map from the view model to the domain model

2) Ask the domain model for the list of rules its applying

3) Use the outputs from 1 & 2 to work out how to apply the rules to the view model instead of the domain model, so basically your "mapping" the rules.

The secret sauce is PostSharp, essentially you attribute your view model using something like this:

   [MapValidationRulesUsing(RuleProviderType = "Security.Domain.GroupRulesProvider, Security.Domain")]

   public class GroupContract : IValidatableContract

MapValidationRulesUsing is a PostSharp attribute and its responsible for running the three steps I've described then applying the rules to the view model. It does this by copying the rules over and mapping them, so maybe our StringNotEmptyRule was applied to Customer.Name.First in the domain and its copied to run on CustomerViewModel.FirstName. Its more difficult with attributes but I'm working on that.

* Circular Dependency *

However its far than perfect, notice that RuleProviderType is a string.

Why?

Well take the concrete example above, GroupContract is in a project called ServiceContract and GroupRulesProvider/Group are in a project called Service. The Service project references the ServiceContracts one, which is fine.

However we now have a dependency from the ServiceContract to the Service project (obviously). How can we copy rules from a (domain) class in the Service project to a project in ServiceContract using PostSharp if ServiceContract needs to build before Service does?

It would work fine if PostSharp ran after the entire solution had built, but it doesn't. So if I clean the solution and build then when PostSharp tries to run on the ServiceContract project it will fall over because the Service project wouldn't yet exist.

My "solution" is to PostSharp run as a post build task on the Service project, telling it to run against ServiceContract. Not tried this yet but the author of P# has indicated it should work.

I'm not sure if this is a hack too far yet....

What do you think of using OnAuthorization instead of OnActionExecuting? That way it will work with AuthorizeAttribute.

We all know that you shouldn't test private methods< , but the same can't be said about protected

This is a great website. I like it alot.