3 ms·

Serves me right. I do an essay about MVC, PVC, and (¬M)VC patterns, and someone comes along and introduces the very interesting MV(VM) pattern. Very interesting

Serves me right. I do an essay about MVC, PVC, and (¬M)VC patterns, and someone comes along and introduces the very interesting MV(VM) pattern. Very interesting!

tomjen3 16y ago
That pattern has been in use for quite some time by .net programmers.
abp 16y ago
You could also have a look at the MVP(Model-View-Presenter)-Pattern. I like it more to say Presentation instead of Presenter. Martin Fowler, for example, has some articles on it.
- abp 16y ago
  I've now seen that the MVP pattern is actually very similiar to the MV(VM) pattern. But i don't really understand the difference. I have, in my applications a basic view that declares all GUI-elements, and special aspects of the GUI, like columns resizable or not in a table. Thats mostly for the designer to build everything out. Now i write my domain models. Then i go on and have a concrete view that inherits the formerly created view and sets up databinding, validation, actions etc. handled by the presentation model. The presentation model is always connected to one specific domain model. So now i have: Abstract view (mostly for the designer) ^ | View -> Presentation model -> Domain Model Besides the presentation, there are validators etc. but all incorporated with the presentation. Now i can test against the presentation, the domain or the concrete views. Also, i can bind multiple presentation models against one view, or one presentation model against multiple views. But i don't call that MV(VM) but MVP.
jashkenas 16y ago
Obligatory MVVM Pattern Wiki link: http://en.wikipedia.org/wiki/Model_View_ViewModel http://en.wikipedia.org/wiki/Model_View_ViewModel
- raganwald 16y ago
  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.
  - equark 16y ago
    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.

Serves me right. I do an essay about MVC, PVC, and (¬M)VC patterns, and someone comes along and introduces the very interesting MV(VM) pattern. Very interesting!

tomjen3 16y ago

That pattern has been in use for quite some time by .net programmers.

abp 16y ago

You could also have a look at the MVP(Model-View-Presenter)-Pattern. I like it more to say Presentation instead of Presenter. Martin Fowler, for example, has some articles on it.

abp 16y ago
I've now seen that the MVP pattern is actually very similiar to the MV(VM) pattern. But i don't really understand the difference. I have, in my applications a basic view that declares all GUI-elements, and special aspects of the GUI, like columns resizable or not in a table. Thats mostly for the designer to build everything out. Now i write my domain models. Then i go on and have a concrete view that inherits the formerly created view and sets up databinding, validation, actions etc. handled by the presentation model. The presentation model is always connected to one specific domain model. So now i have: Abstract view (mostly for the designer) ^ | View -> Presentation model -> Domain Model Besides the presentation, there are validators etc. but all incorporated with the presentation. Now i can test against the presentation, the domain or the concrete views. Also, i can bind multiple presentation models against one view, or one presentation model against multiple views. But i don't call that MV(VM) but MVP.

jashkenas 16y ago

Obligatory MVVM Pattern Wiki link: http://en.wikipedia.org/wiki/Model_View_ViewModel http://en.wikipedia.org/wiki/Model_View_ViewModel

raganwald 16y ago
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.
- equark 16y ago
  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.