Why should I use MVVM when it breaks built in riaservices functionality

Question

I'm struggling to grasp why MVVM is really a good pattern to implement in riaserivces, To me there's nothing but trouble to it, it just add's another tier that I have to code. I Get that I could change the UI, but really I don't need to. Instead i won't be able to user out of the box functionality with riaservices, datagrid, dataform all controls require some implementation. Why can't it just be simple?

Is there really no way to get MVVM to automatically set "IsBusy" and all the dataform edit functionality. It's like reinventing the wheel to me, and it seems that I'd be able to write code much faster just using riaservices

Answer 1

Some people would ask "why should I use RIA Services when it breaks MVVM?" :-) I'm not enough of a RIA Services expert to answer your precise questions about IsBusy and retaining the easy edit functionality with MVVM, but keep in mind that both MVVM and RIA Services are sky high on the hype rollercoaster right now, and pretty much any blog or dev site will try to convince you why they're the best things since sliced bread. If you don't see the need for a technology or a pattern, don't use it.

That said: In my opinion, what RIA Services is really meant to do is let you slap a DataGrid on a page and let you look into a database with it. That's why pretty much all the samples out there do just that, and most of them don't bother with MVVM because it gets in the way of the slick wizards and drag-and-drop development, which is where RIA really shines. If that's what you're doing, RIA without MVVM probably makes more sense than vice-versa.

Answer 2

MVVM doesn't break RIAServices. It's always about how you implement the pattern. Remember, MVVM is Model-View-ViewModel. The ViewModel does the heavy lifting, and the view binds to models.

With RIA + MVVM, the ViewModel simply handles the RIA services calls. It can still use the models RIA services provides and binds these to the views. IsBusy is no problem whatsoever, that's typically a view state you can raise.

Why use the two together? Precisely because you don't know what might change and for testing and flexibility. I don't know about you, I'd rather test my view models and logic without depending on a service and database being available. With MVVM, the View Model can do that - I can stub a "fake" layer that provides me models to test with. That also means I can build out code and let the designers design even if I haven't worked out the services or build that portion yet.

Once it is ready, then in the production version I wire in the "true" RIA model and go from there.