1 Replies - 6369 Views - Last Post: 18 September 2010 - 10:24 AM

#1 wydok   User is offline

  • New D.I.C Head

Reputation: 0
  • View blog
  • Posts: 25
  • Joined: 16-March 09

MVVM and Silverlight: Some Architectural Questions

Posted 17 September 2010 - 11:34 AM

Maybe this post should go into a more generic forum, since it's more about design patterns with SilverLight and actually having to do with the physical C# code... but here goes.

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, where should the validation be done: the View or the ViewModel? A book has an ISBN number. It is a certain length and in a certain format. Traditionally (the the way we wrote code in our company), validation would be in the object that represents the data (the Model), and an exception would be thrown. (Actually, traditionally we'd also have validation in Javascript...but that's a moot point). Validation was being done at the Model level because our application will, for some of our tables, modify data in backend processes independent of a UI. In order to avoid a garbage-in-garbage-out situation, we wrote validation in the classes that represented the data. Is this still true in the MVVM design pattern? I have seen a lot of blog posts written about the IDataErroInfo interface that allows you to bind to properties in the ViewModel and use the ValidatesOnDataErrors property for returning custom validation errors. In the examples, the IDataErroInfo interface was implemented at the ViewModel level. I think in our case we want to avoid that.

I am asking about validation mostly because I am also trying to avoid situations where the SAME validation is written on multiple levels of the architecture. This was a paradigm we used in our old ASP/JS/COM+ application, and it was nothing but a headache. ASP3.0 code run on the server used to affect the presentation of the HTML served to a web browser based on data, Javascript used to dynamically change that presentation and show validation errors, and validation in the business rules in our COM+ objects).

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

Is This A Good Question/Topic? 0
  • +

Replies To: MVVM and Silverlight: Some Architectural Questions

#2 wydok   User is offline

  • New D.I.C Head

Reputation: 0
  • View blog
  • Posts: 25
  • Joined: 16-March 09

Re: MVVM and Silverlight: Some Architectural Questions

Posted 18 September 2010 - 10:24 AM

Oh, since should have been obvious from the get-go, but it turns out that the code that does validation is not serialized in objects when using a WCF service, so my entire idea of having validate-once code is shot anyway.

Was This Post Helpful? 0
  • +
  • -

Page 1 of 1