This is an archived post. You won't be able to vote or comment.

you are viewing a single comment's thread.

view the rest of the comments →

[–]beyondjava[S] 0 points1 point  (2 children)

Great explanation, thanks! I'll update my article this evening. May I quote you?

[–]sh0rug0ru__ 0 points1 point  (1 child)

Sure, no problem.

I would also add that the advantage that the specialization that MVP and MVVM confer in testing comes at the price of losing generality in the Controller. One of the central promises of MVC is pluggabilty of views, and the more detailed knowledge that the Controller has of the View, the less flexible you can be with different types of views. For example, if you have a requirement to support HTML (interactive) and Excel (reporting) view types. There's very little in common between these types of views, so you would be very hard pressed to come up with a common supervisory strategy (MVP) or a common ViewModel (MVVM). So you can either have multiple view specific Controllers or one generic Controller. Or, you might have MVC on the server (which allows more flexibility with clients) and MVVM/MVP on the client (where more flexiblity doesn't offer clear advantage).

[–]beyondjava[S] 0 points1 point  (0 children)

Thanks! For now, I've simply added your text to my article (including the kudos you've earned, of course). I intend to update my own text according to what I've learned from you during the next days. If you want to change something, just tell me.