Framework Design Patterns

Introduction

In web development, choosing the right architectural pattern is critical to a project’s success. As application complexity grows, developers face a wide range of choices — from the classic MVC to modern MVVM, and from traditional monolithic architectures to microservices. This article provides an in-depth analysis of three core design patterns (MVC, MVP, MVVM) and compares the directory structure differences and trade-offs between traditional web frameworks and microservice frameworks.

Part 1: Web Framework Design Patterns

1. MVC (Model-View-Controller)

Structure diagram:

┌─────────┐     ┌─────────┐     ┌─────────┐
│  View   │◄───►│Controller│◄───►│  Model  │
└─────────┘     └─────────┘     └─────────┘

Component responsibilities:

• Model: Data layer — responsible for business data and business logic
• View: Presentation layer — responsible for rendering the user interface
• Controller: Control layer — handles user input and updates the model

Workflow:

1. The user initiates a request through the View
2. The Controller receives and parses the input
3. The Controller updates the Model state
4. The Model notifies the View to refresh

Advantages:

• Clear separation of responsibilities
• Decoupling between view and model
• Multiple views can share a single model

Disadvantages:

• Controllers can become bloated
• View and controller become over-coupled
• Unit testing is difficult

Typical frameworks: Ruby on Rails, Django, Spring MVC

2. MVP (Model-View-Presenter)

Structure diagram:

┌─────────┐     ┌────────────┐     ┌─────────┐
│  View   │◄───►│ Presenter  │◄───►│  Model  │
└─────────┘     └────────────┘     └─────────┘

Component responsibilities:

• Model: Data layer — same as in MVC
• View: Passive interface — only responsible for display
• Presenter: Central hub for business logic

Differences from traditional MVC:

• The View no longer communicates directly with the Model
• The Presenter replaces the Controller and contains more logic
• The View communicates with the Presenter through an interface

Advantages:

• The View is fully passive and easy to test
• Business logic is centralized in the Presenter
• Cleaner decoupling of the user interface

Disadvantages:

• The Presenter can grow too large
• Increases interface complexity
• Slightly steeper learning curve

Use cases: Windows Forms applications, Android applications

3. MVVM (Model-View-ViewModel)

Structure diagram:

┌─────────┐     ┌──────────────┐     ┌─────────┐
│  View   │◄───►│ ViewModel    │◄───►│  Model  │
└─────────┘     └──────────────┘     └─────────┘
    ▲                    ▲
    └──── Data Binding ──┘

Key innovations:

• ViewModel: An abstraction of the view, containing its state and behavior
• Two-way data binding: Automatic synchronization between the View and ViewModel

Component responsibilities:

• Model: Data layer
• View: Declarative UI description
• ViewModel: View state and behavior model

Advantages:

• Minimal view code
• Automated view-state synchronization
• Excellent testability
• Clear separation of concerns

Disadvantages:

• Debugging data bindings is complex
• Higher memory consumption
• Steep initial learning curve

Typical frameworks: Vue.js, Angular, Knockout.js

Design Pattern Comparison

Part 2: Traditional Web Frameworks vs. Microservice Frameworks

1. Traditional Web Framework Architecture (Monolithic)

Example directory structure:

project/
├── app/
│   ├── controllers/   # Controllers
│   ├── models/        # Data models
│   ├── views/         # View templates
│   └── services/      # Business services
├── config/            # Configuration
├── public/            # Static assets
├── tests/             # Tests
└── main.go            # Entry point

Characteristics:

• Single codebase: All feature modules in one project
• Vertical layered structure: Clear separation of control, business, and data layers
• Shared database: All services use the same database
• Centralized governance: Uses a unified technology stack and framework

Advantages:

• Simple to develop and debug
• Simple to deploy and operate
• Easy transaction management
• Fast development in the early stages

Disadvantages:

• Becomes bloated as scale grows
• Technology stack is fixed and hard to change
• Limited scalability
• A change in one place can break everything

2. Microservice Framework Architecture

Example directory structure:

project/
├── auth-service/      # Authentication service
│   ├── src/
│   │   ├── controllers/
│   │   ├── models/
│   │   └── services/
│   ├── Dockerfile
│   └── main.go
│
├── user-service/       # User management service
│   ├── src/
│   │   ├── controllers/
│   │   ├── models/
│   │   └── services/
│   ├── Dockerfile
│   └── main.go
│
├── api-gateway/        # API gateway
├── docker-compose.yml   # Container orchestration
└── README.md

Core characteristics:

• Service decomposition: Split into independent services by business function
• Independent databases: Each service has its own dedicated database
• API-driven: Services communicate through APIs
• Infrastructure components: Gateway, service registry, configuration center

Advantages:

• Independent deployment and scaling
• Diverse technology stacks
• Stronger fault tolerance
• Greater team autonomy

Disadvantages:

• Distributed system complexity
• Data consistency challenges
• Significantly higher operational costs
• Complex debugging and monitoring

3. Architecture Comparison

Part 3: Hybrid Architecture in Practice

In practice, layered microservice architecture is becoming the mainstream trend:

┌───────────────────────────────┐
│          API Gateway          │
└───────────────┬───────────────┘
                │
     ┌──────────┴──────────┐
     ▼                     ▼
┌─────────────┐     ┌─────────────┐
│  Order      │     │  Payment    │
│ Service     │     │ Service     │
├─────────────┤     ├─────────────┤
│ Controller  │     │ Controller  │
│ Service     │     │ Service     │
│ Repository  │     │ Repository  │
└─────────────┘     └─────────────┘
        │                  │
        ▼                  ▼
┌─────────────┐     ┌─────────────┐
│  Order DB   │     │  Payment DB │
└─────────────┘     └─────────────┘

This architecture combines:

• The independence and scalability of microservices
• Modular layered design within each service (MVC/MVVM per service)
• Domain-driven design principles
• Lightweight service communication (e.g., gRPC)
• A unified entry point via the API gateway

Part 4: Architecture Selection Recommendations

1. Consider project scale:

   • Simple projects: Traditional framework + layered architecture
   • Large projects: Microservices + domain-driven design

2. Evaluate team capability:

   • Small teams: Monolithic architecture is more efficient
   • Large teams: Microservices support parallel development across teams

3. Technology selection strategy:

   Project Start → {Scale and Complexity}
   → Simple app → Traditional Framework + MVC
   → Complex app → {Need reactive UI?}
     → Yes → SPA Framework + MVVM
     → No  → Microservices + Layered per service

4. Evolutionary architecture mindset:

   • Start monolithic, decompose as needed
   • Prioritize decoupling the most frequently changed components
   • Adopt a “Monolith First” strategy

Conclusion

Regarding web framework design patterns:

• MVC remains the foundational paradigm, suitable for traditional web applications
• MVP excels in scenarios with high testing requirements
• MVVM is the preferred choice for modern reactive applications

Regarding architecture selection:

• Traditional web frameworks simplify the development workflow but have limited scalability
• Microservice frameworks solve scalability problems but introduce new complexity
• Hybrid architectures are becoming the mainstream approach for balancing practicality and flexibility

Ultimately, there is no “best” architecture — only the architecture that is “most appropriate for the current stage.” Successful system design requires a deep understanding of business requirements, team capabilities, and technology trends, with continuous adjustment and optimization as the system evolves.