I tend to think of MV* as a misnomer, because people generally seem to understand now that "Model" constitutes the business logic and any associated business da

I tend to think of MV* as a misnomer, because people generally seem to understand now that "Model" constitutes the business logic and any associated business data (be it a database or document). But every single environment is going to have a different circle drawn around what a View is - what is provided, what you are expected to build yourself, and how to interface the two. For instance, the V and C are partially a separation assuming it is appropriate to have a decoupling of input and output. The most important concept is that your model should be separate from all that. If you want to show the model in some new clever way, that should be via some View-ish functionalities manipulating data gained from the model. If you want some cool new behavior or functionality though, you should put that business logic entirely within the model. Then, you can properly control the boundary between the two sides - if all you do is add new methods or expose new data without changing behavior, you know that everything outside the model will still work without change. Start changing existing behavior, and your UI pieces will likely need to change to accommodate that.