>Yes, I think my LinqToSql BO wrapper does serve as a ViewModel of sorts. It is a Business Object class with an Entity property on it (that the West Wind LinqToSql Business Object Wrapper class populates for me).
>On that BO class, I add any methods I want the BO to have (validation methods, handling default values for New Entities, etc) and any *additional* "presentation properties" that I want to tack onto the BO.

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?

>
>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
>>>
>>>
>>>.