>The only snag I see there is that all Views don't neccessarily need the same "presentation properties" - so don't you end up burdening the BO class with stuff that is only needed by certain Views?


From a theoretical standpoint, sure, it breaks a few rules. But from a real world impact, we are talking about only a handful of supplemental properties. In all the BOs I've built (Customer, Invoice, Quote, Shipper, User, Employee, etc.), maybe I've added 3 to 5 additional properties on each one to serve what is usually 1 view, but sometimes 2 or 3 different views at the most. If things really get crazy, there might be as many as 10 presentation properties to handle all the views. It still seems like less of an overall burden on the application as a whole to add a few presentation properties right on the BO, rather than dropping an entire ViewModel< -- >Model Mapper implementation on my app (homegrown or commercial). Talk about a burden.

Now look, these additional properties will be implemented somewhere. Why not stick them onto something that already exists (the BO) as little light-weight tag-alongs, rather than create an entirely free-standing ViewModel object, where I put these innocent properties and then I have to REPLICATE all the real properties from the Model too. Is that how this magic ViewModel character makes things "cleaner"? Yuck! Oh, wait, I almost forgot... but look how clean my BO is! No thanks.









>
>>
>>And, yes, when working with my BO's, you have to access some properties right off the BO (the custom presentation properties I've added) and some come from BO.Entity (the real data from the database row), so you do have to know where to get the data you are after. By doing this, most of my UI binding is against the BusinessObject.Entity properties, and a few UI bindings go against the supplemental presentation properties I’ve added right on the BO.
>>
>>
>>
>>>Hi,
>>>Firstly - no argument that implementing MVVM is more work (on both design and implementation), can often be overkill - and may well be in your current situation.
>>>
>>>But a few thoughts:
>>>
>>>Most of the argument in your blog is against the amount of code required for the ViewModel--Model part of the equation. In your case (using a LinqToSql Entity as the Model) then the lines are a bit blurred since the entity object might almost be regarded as a ViewModel in itself. If that's the case you could just pass a reference to the entire entityobject to the View and you'd be in the same situation as now with minimal code.
>>>
>>>But your blog makes no reference as to where you are locating any ancilliary code (business logic, command handling etc). The ViewModel code can be a good place for that. Obviously it shouldn't be in the UI and if you want to attach it to the Entity classes you end up with code (probably in partial classes) that doesn't really belong there?
>>>
>>>Of course it you ever wanted to port the ASP.NET app to WPF, or SilverLight or even WinForms then having based consistently on an MVVM pattern would probably mean that 80-90% of your codebase would be re-usable....
>>>
>>>I may be over-egging the advantages of MVVM with ASP.NET - I'm working on a WPF app where (because of XAML, DataTemplating etc) the ViewModel-View side is a *very* natural fit. We're also using the EntityFramework so, as in your case, the Model is essentially the EntityObject and we sometimes just pass that intact to the View (although I do have reservations about this...)
>>>
>>>Just my 10c - I'd be interested in any other views,
>>>Viv
>>>
>>>
>>>>Model < --- > ViewModel < -- > View
>>>>
>>>>It's great theory, but come on!
>>>>
>>>>Just say No Way!!
>>>>
>>>>http://therealmattslay.blogspot.com/2009/11/model-view-model-view-no-way-for-now.html
>>>>
>>>>
>>>>.