Silverlight / MVVM Design: what is my model and where to put the logic?

Question

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

Answer 1

I think you're touching on the aspects of MVVM that A) beg the most questions and B) have the least amount of consensus.

The pattern implies three layers: the Model is the data, the View is the screen, and the ViewModel sits between them. I'm starting to think this is inaccurate, or at least non-optimal. From the Data to the screen, here is what I'm working towards:

A) Service layer: this code could be actual services or wrappers around ADO.NET calls. Whatever the flavor, its job is to interact with the physical data source. It does this using Entities (not necessarily EF classes, just classes that represent the database).

B) Entity layer: these are the classes obtained by the Service layer. All communication to and from the physical data source happens via these entity classes.

C) Data Model layer: these classes wrap/manage the Entity layer. Specifically, they implement INotifyPropertyChanged so they can be used later in the View and expose methods and properties for accessing the Entity layer. This abstraction allows the Entity layer to be changed and updated without adversely affecting the ViewModel or View.

D) ViewModel layer: the ViewModel class, which also implements INotifyPropertyChanged, manages the interaction between the View and the Data Model classes. Commands and specific visual property formatting (say combining FirstName and LastName into a FullName property) occur at this layer. The ViewModel can further abstract the Data Model class, but at this point it should not be necessary.

E) View layer: the final View (Window, Page, or UserControl). My hard and fast rule is to maintain a 1 ViewModel per View relationship (and vice versa).

I'm calling these layers because this is the logical idea: how they are physically implemented will be based on your situation.

FWIW, I've been teaching MVVM a lot recently and solidifying my ideas about the architecture. The first thing I say when teaching it is that there are as many ways to implement MVVM as there are people implementing MVVM. While this is obviously a little bit of hyperbole, the idea stands that you must find what works best for you and your situation.