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