Why MVC Still Matters: Navigating Architecture Choices for Modern Apps

Background and Problem

I tend to use the term “architecture” cautiously because the industry has many architecture masters and patterns, yet my own experience is limited. The term can feel lofty and abstract, leading to debates like “PHP is the best language” unless tied to concrete problems.

My viewpoint: start from the problem to discuss the architecture pattern (technical solution) and base the discussion on established software design/development principles.

I wrote this article to share solutions to problems we encountered, hoping to spark discussion and learn from others.

From the Presentation Layer: MVC

Software development is the core of the process: receiving product and visual design requirements, then delivering a usable end product. A unified software development architecture underpins quality.

Because the discussion involves customer‑facing UI, I start with MVC.

MVC in Classic Three‑Layer Architecture

MVC is a generic architecture pattern that originated in the PC era, became popular in web development, and is now widely used in mobile internet.

In the classic three‑layer model, MVC belongs to the presentation layer.

Different companies interpret MVC differently. Below are examples from Microsoft, Apple/Stanford, Martin Fowler, and Google.

Microsoft

Microsoft’s 2014 diagram shows Controller referencing View and Model; View can reference Model. Updated 2021 diagram reflects the same.

Key points from Microsoft:

Controller can reference View and Model.

View can reference Model.

Model is typically passive.

Microsoft emphasizes that controllers should not become overly complex; business logic should be pushed out to domain models.

Apple & Stanford

Apple’s older diagram does not allow View to reference Model, unlike Microsoft.

Martin Fowler

Fowler’s MVC diagram differs from both Microsoft and Apple, illustrating alternative relationships.

Google

Google’s description also presents its own take on MVC.

Discussion Points

Should View reference Model?

How to prevent Controller bloat?

What are the implications of View‑>Model and Model‑>View relationships?

Answers depend on concrete scenarios.

Related Patterns and Practices

Martin Fowler and Eric Evans discuss Model design in DDD, distinguishing between anemic and rich models.

In Java Web development, Model design has sparked intense debate.

Solutions

Let View‑>Model handle UI layout via factory pattern, reducing Controller responsibilities.

Split responsibilities into multiple Controllers (e.g., Delegate, DataSource).

Introduce other Controller types (e.g., DataSourceController) similar to Android’s Adapter‑ViewHolder.

These approaches address the earlier questions about Controller bloat and View‑Model references.

MVVM Consideration

Given the focus on testability, MVVM is a strong candidate: it promotes data binding, separates concerns, and aligns with SwiftUI+Combine or Kotlin multiplatform.

MVVM can be adopted fully or partially to avoid over‑design in simple scenarios.

Final Thoughts

There is no absolute right or wrong in architecture; the choice must solve the core problem in the given context.

Controllers should not become overly complex; push business logic into domain models.

Ultimately, ensuring product quality in complex, evolving systems requires testability, which leads me to favor MVVM (or a lightweight variant) for its maturity and support in modern mobile development.