I forked from thread When using MVVM pattern, should code relating to property changes go in the setter or an event?
My understanding of the MVVM pattern is OK with the View and the ViewModel parts...
But what about the Model part? Is it the technical object model (EntityFramework SelfTracking generated classes, and then located behind the web services, then with ALL the business logic in the server) or an Application Logic Model (which we would recreate on the Silverlight client based on the entity classes of course -thanks PRISM project linker-, it would present GUI oriented operations, with more business logic available, and would encapsulate the dirty technical stuff to access the WS to propagate the modifications on entities to database)?
(Personnaly, I'm thinking of the second one)
In our Silverlight/WCF (not RIA) project, we manage documents. We have Views for displaying these documents (InboxView.xaml for instance), which sticks to a InboxViewModel.cs, containing a list of documents to be displayed. The ListBox in the InboxView is DataBound to a DocumentList ObservableCollection property in the InboxViewModel. But the listbox ItemTemplate is DataBound to a DocumentViewModel.cs, which encapsulates the entity generated Document.cs class.
Point is this DocumentViewModel is actually used by other views... (partially OK for me, not at all if MVVM does stipulate a bijection between Views and ViewModels? but this is not my point...).
In my humble opinion, I'd rather have a DocumentModel.cs instead of the DocumentViewModel.cs, which could be shared by several ViewModels (InboxViewModel, EditDocumentViewModel...) and encapsulates calls to WS in order to trigger business operations server-side with client-side modified entities.
We would then have an Application Logical Model or GUI oriented Model (M-V-VM), in addition (and below, layers-wise speaking) to the ViewModels (M-V-VM) and the Views (M-V-VM). All on the Silverlight side.
But then 2 questions:
1- If retaining my humble opinion, would it be ok to DataBind an ItemTemplate directly to Model objects? As none of the Views are directly bound to a DocumentModel, but bound to a property in the InboxViewModel (for instance) which is a DocumentModel object?
2- More generally, what would be the part of business logic implemented server-side and client-side?
As the server is intended to expose WS to other (fictional future or future fictionnal :p) applications, do we really want to put all the first application business logic in the server, or expose only atomic operations through the WS and let all the applications implement their proper logic instead?
My tech lead keep flooding me with references, but that/he doesn't bring me any answer, and moreover, I'm just trying to think on my own here.
Thanks to all of you guys...
Cheers