Interesting. The primary motivation as expressed in that link seems to be the separation of concerns to facilitate having a specialist UX designer and a specialist programmer working in a decoupled way.
My experience is that this happens only after the view has matured. It's hard to foresee everything that should be in the view model. The UX guy will want certain things in the API and there will be a lot of interplay between the two roles to start. The advantage is that once the model has matured, the UX guy has a lot of flexibility. Refactoring the UX is pretty independent of the view model. The view model also tends to be more robust because it's easy to unit test, unlike some jQuery mashup.
Comments
Interesting. The primary motivation as expressed in that link seems to be the separation of concerns to facilitate having a specialist UX designer and a specialist programmer working in a decoupled way.
My experience is that this happens only after the view has matured. It's hard to foresee everything that should be in the view model. The UX guy will want certain things in the API and there will be a lot of interplay between the two roles to start. The advantage is that once the model has matured, the UX guy has a lot of flexibility. Refactoring the UX is pretty independent of the view model. The view model also tends to be more robust because it's easy to unit test, unlike some jQuery mashup.