My company is taking an old ASP 3.0 (with COM+ for the business logic) and rewriting it as a Silverlight application. It was decided to do it this way instead of using ASP.NET due to some preceived limitations in the crossbrowser support in ASP.NET (apparently "some stuff" doesn't work in Safari).
Anyway, regardless of WHY Silverlight has been chosen, I have some questions regarding the Model-View-ViewModel (a variant of the Model-View-Controller) design pattern.
I have a feeling the answer is going to be "whatever works for your company", but I would like some opinnions.
Here is what I was thinking about using as are architecture:
Model: C# objects represent a row in a table. We decided NOT to go the routes of Entitites automatically via WCF RIA Services because our database connections will never actually be stored on the web.config. There are probably ways around this, but for the time being this is the design I am taking. To be honest, this part I am still fuzzy on, but is rather minor in the context of my current questions. Anyway...these objects are serialzed, and data from the objects are available in our Silverlight application via Silverlight-Enabled WCF Services.
View: UserControls written with XAML. Following what I understand to be the MVVM concept, there will be little to no code-behind and the view should (as much as possible) be just XAML.
VieModel: C# objects for controling the data presented to the View. The objects will call WCF services to return the data from the Model.
Here are my questions:
Is there a general consenus on whether the ViewModel layer should abtract all of the data in the Model object and have THAT be bound to the View, or should the ViewModel have Model objects as properties which could then be bound to the View? I am thinking the ViewModel should be what is bound directly, because that is basically the point of having the ViewModel, right? But, if the ViewModel abstracts the data, wouldn't that duplicate work? For example, if you have a Book and a BookViewModel object, and the Book has a property called Title, the BookViewModel would also have to have a property called Title. Even if all it actually does is set the value on the internally accessible (to the BookViewModel) Book object.
Also... as a related question or discussion point. I'm a bit fuzzy on the difference between MVVM, MVC, and MVP. As far as I understand, all three design patterns split out an application into presentation, behavior, and data. But besides te fact that MVVM is supposed to reduce or eliminate event-based code in the View (replaced with data and command binding), I'm not entirely sure what, if anything, is the difference between MVVM, MVC, and MVP.
This post has been edited by wydok: 17 September 2010 - 11:46 AM