In my experience, the most common way people get MVC wrong is equating "model" to "data model", and "controller" to "business logic". Since the controller is re

In my experience, the most common way people get MVC wrong is equating "model" to "data model", and "controller" to "business logic". Since the controller is responsible for also interacting with a specific view, you haven't made your software decoupled, rather just spread logic into three buckets. IMHO, the real goal is establishing a somewhat stable boundary between the business logic and state and your UX, both to allow logic to be reused in other presentations and to allow both to evolve without constantly breaking code. MVC vs MVP or MVA is a difficult distinction IMHO, because the UX portion is really split between the view and controller, which may also include interactions with a more sophisticated UI system (for example, with its own input event handling and data binding). For a lot of these systems, what constitutes a "View" or a "Controller" really depends on the infrastructure provided to the developer. Template-based web frameworks can actually be fairly close to MVC - the controller handling the input request, translating that to commands against the model, and then taking data from the model and handing that off to the view to present to the user. A component-based system has components which constitute the UI presentation, but also handle user input and may have data binding. At this point you are far closer to "Model View Adapter", which as the article points out is what you'll see in most componentized frameworks. Again IMHO, but the difference between MVA and "Model View ViewModel" (MVVM) are really around implementation strategies for the adapter layer. That there are different strategies is one of the reasons that attempts by frameworks to simplify this adapter layer result in different terminology (for instance, ViewControllers and Delegates and DataSources, vs ViewModels)