Mar 3, 2011 at 3:19 PM
Edited Mar 3, 2011 at 4:20 PM
Ok so you have 2 questions there, the easy one 1st
I did decide to not register with the Mediator for every ViewModel instance (by using the ViewModelBase class) in Cinch V2. But that is easy to do you just need to Mediator.Instance.Register(this); anywhere you want to use the Mediator, and Mediator.Instance.Unregister(this)
when you want to unregister.
Problem is with MVVM is there is no one way. Some people like to expose a current Model (I used to do that too), others expose all the properties needed from the model, and just have the ViewModel expose these properties. If you go down the current model
within a Cinch ViewModel you will have to do the validation of the model yourself, and you will need to make sure you EF model objects implement IDataErrorInfo and you will have to do ALL the validation yourself, Cinch will not help you there.
Or what you could do is have a Cinch ViewModel expose the properties required off the model, and either write/get straight through to the backing EF model, or only propagate the changes back to the EF model at certain points, such as get data from
EF model on ViewModel load, and only put data back on Valid and Saving or something like that. You could do this with some sort of mapper.
I think I would tend to go for the approach where you have only the properties exposes in the ViewModel that you need from the Model, and you get/set directly to the Model, and that way you can use the standard Cinch validation methods, you would of course
also have to ensure you do not save your model if the ViewModel is invalid.
To be honest there are so many ways of doing this its not even funny, its all down to personal preference at the end of the day, Cinch is a MVVM framework, so the emphasis is on the ViewModel, and not so much the Model, but you can do anything you like really,
it really is down to you.
There was a message here : http://cinch.codeplex.com/discussions/246989 where that chap wanted to use NHibernate validation and feed those broken rules back into a Cinch ViewModel, that
would also work.
Also one thing, EF objects are really server side objects where you would want to persist them using the Entities DataContext, I would tend to transfer POCO objects to the Client (WPF) say using WCF, and then back to the server as POCO, and convert those
back into Entity classes, and Attach them to context and save them to DB.
Like I say a million ways to skin a cat really.
One last thing, the Cinch.DataWrapper<T> is really only intended to wrap primitives such as string, int, double etc etc, not complex objects. It was really just so I could have a single object which held a value and a IsEnabled for the field where
I showed the value to save me time creating loads of ViewModel properties for IsEnabled.