前端框架中的设计模式青训营X豆包MarsCode 技术训练营AI｜豆包MarsCode AI 刷题前端开发在不断演进

前端开发在不断演进的过程中，涌现出了各种各样的框架和库，以提高开发效率和代码质量。在这些框架中，设计模式起到了至关重要的作用，帮助开发者组织代码、解决问题并保持可维护性。本文将深入探讨前端框架中常见的设计模式，通过对比分析它们的优缺点和使用案例，助力读者更好地理解如何在实际项目中应用这些模式。

1. MVC（Model - View - Controller）

MVC 是一种经典的设计模式，将应用程序分为三个部分：模型（Model）、视图（View）和控制器（Controller）。模型负责管理数据和业务逻辑，例如在一个电商系统中，模型负责商品数据的存储、读取，如从数据库获取商品信息、处理商品库存的增减逻辑以及订单的处理等业务规则。视图负责显示界面，以直观的形式将数据呈现给用户，比如展示商品列表页面、商品详情页面等。控制器则承担协调模型和视图之间交互的重任，接收用户在视图上诸如点击商品加入购物车、提交订单等操作，并调用模型中的相应方法处理，随后更新视图显示购物车数量变化或订单提交结果等。在前端框架中，像 Angular 和 Backbone.js，MVC 被广泛应用。

其优点显著，首先它分离关注点，让代码结构更为清晰，不同部分各司其职，极大地增强了可维护性和可扩展性。这意味着开发人员能专注于特定层的开发，当修改某一层时，只要接口不变，对其他层的影响较小。例如，若要更改商品列表的展示样式（视图层），只要商品数据获取接口（模型层）不变，就不会影响到控制器层的逻辑。其次，它降低了代码耦合度，使团队协作更加高效，不同成员可分别负责不同层的开发工作，如后端开发人员专注模型层的数据处理，前端开发人员负责视图层的构建和控制器层的部分逻辑编写。再者，界面逻辑和业务逻辑分离的特性便于单元测试，能够单独对各层进行测试验证，可方便地测试模型层的订单处理逻辑是否正确，而不受视图层和控制器层的干扰。

然而，MVC 也并非完美无缺。对于复杂的应用，控制器可能会变得庞大和难以维护，因为它需要处理大量来自视图的操作并协调模型。例如在一个大型电商平台，有众多商品操作、用户操作、订单操作等都在控制器中处理，代码量会快速增长。而且严格的分层可能会导致交互复杂度增加，在出现问题时调试难度加大，例如当商品库存更新后视图未及时同步，排查问题可能涉及多层代码的检查，要从视图层的显示逻辑，到控制器层的调用，再到模型层的库存更新逻辑逐一排查。

案例方面，在 Angular 框架中，开发者可以通过创建组件（Component）来实现 MVC 模式。组件充当控制器，模板（Template）充当视图，而服务（Service）则充当模型，共同构建一个符合 MVC 设计模式的前端应用。例如：

import { Component, OnInit } from '@angular/core';
import { ProductService } from './product.service';

@Component({
  selector: 'app-product-list',
  template: `
    <ul>
      <li *ngFor="let product of products">{{ product.name }}</li>
    </ul>
  `,
})
export class ProductListComponent implements OnInit {
  products: any[];

  constructor(private productService: ProductService) {}

  ngOnInit() {
    this.products = this.productService.getProducts();
  }
}

在此示例中，ProductListComponent 作为控制器，通过 ProductService（模型）获取产品数据，并在模板中展示（视图）。

再比如，在一个新闻网站应用中：

import { Component, OnInit } from '@angular/core';
import { NewsService } from './news.service';

@Component({
  selector: 'app-news-feed',
  template: `
    <div *ngFor="let news of newsList">
      <h3>{{ news.title }}</h3>
      <p>{{ news.content }}</p>
    </div>
  `,
})
export class NewsFeedComponent implements OnInit {
  newsList: any[];

  constructor(private newsService: NewsService) {}

  ngOnInit() {
    this.newsList = this.newsService.getNews();
  }
}

这里的 NewsFeedComponent 负责协调 NewsService 与视图之间的交互，从 NewsService 获取新闻数据并在模板中展示新闻标题和内容。

2. MVVM（Model - View - ViewModel）

MVVM 是另一种常见的前端设计模式，它在 MVC 的基础上引入了 ViewModel 层。ViewModel 扮演控制器和模型之间的中间人角色，负责将模型数据转换为视图可用的格式，同时也将视图的操作转化为对模型的更新。这个模式在 Vue.js 和 Knockout.js 等框架中得到了广泛应用。

MVVM 的优点众多，其中双向数据绑定是一大特色，它使视图与模型之间的同步更加简便。当 ViewModel 中的数据发生变化时，视图会自动更新；反之，用户在视图中的修改也能及时反馈到 ViewModel 和模型中。这大大减少了手动更新视图的代码量，提高了开发效率。例如在一个数据可视化应用中，当数据模型中的数据发生变化时，绑定到该数据的图表视图会自动重新绘制。并且分离了视图和业务逻辑，便于前端和后端开发者的协同工作，前端专注于视图和 ViewModel 的开发，后端专注于模型的构建。

不过，对于复杂应用，ViewModel 可能会变得复杂，难以管理，因为它需要处理大量的数据转换和视图操作逻辑。过多的数据绑定可能导致性能问题，尤其是在大型应用中，如果没有合理控制数据绑定的范围和频率，可能会出现性能瓶颈，所以需要谨慎使用。

以 Vue.js 框架为例，开发者可以通过创建 Vue 实例来应用 MVVM 模式。Vue 实例中的 data 属性充当模型，模板充当视图，而计算属性（Computed）和方法（Methods）则充当 ViewModel，负责处理业务逻辑和数据转换。如下所示：

<template>
  <div>
    <input v-model="firstName">
    <input v-model="lastName">
    <div>{{ fullName }}</div>
  </div>
</template>

<script>
export default {
  data() {
    return {
      firstName: '',
      lastName: '',
    };
  },
  computed: {
    fullName() {
      return `${this.firstName} ${this.lastName}`;
    },
  },
  methods: {
    saveUser() {
      // 这里可以编写将用户信息保存到模型（如发送到后端API）的逻辑
      console.log(`Saving user: ${this.fullName}`);
    },
  },
};
</script>

在这个例子中，data 中的数据作为模型，模板中的输入框和显示姓名部分是视图展示和交互部分，而 computed 中的 fullName 方法作为 ViewModel 的一部分，将 firstName 和 lastName 组合成可供视图展示的完整姓名，methods 中的 saveUser 方法则处理视图操作（如保存用户信息）与模型的交互。

再看一个音乐播放器应用的案例：

<template>
  <div>
    <img :src="albumCover" alt="Album Cover">
    <h2>{{ songTitle }}</h2>
    <audio :src="audioSrc" controls @ended="nextSong"></audio>
  </div>
</template>

<script>
export default {
  data() {
    return {
      albumCover: '',
      songTitle: '',
      audioSrc: '',
      playlist: [],
      currentSongIndex: 0,
    };
  },
  computed: {
    // 根据当前歌曲索引获取专辑封面路径
    albumCover() {
      return this.playlist[this.currentSongIndex].cover;
    },
    // 根据当前歌曲索引获取歌曲标题
    songTitle() {
      return this.playlist[this.currentSongIndex].title;
    },
    // 根据当前歌曲索引获取音频文件路径
    audioSrc() {
      return this.playlist[this.currentSongIndex].src;
    },
  },
  methods: {
    nextSong() {
      this.currentSongIndex++;
      if (this.currentSongIndex >= this.playlist.length) {
        this.currentSongIndex = 0;
      }
    },
  },
};
</script>

这里的 computed 属性根据 data 中的数据（如播放列表信息）计算出视图所需的专辑封面、歌曲标题和音频源等信息，methods 中的 nextSong 方法处理视图中音频播放结束后的下一首歌曲切换操作，很好地体现了 ViewModel 在 MVVM 模式中的数据转换和视图操作处理功能。

3. Flux

Flux 是一种用于管理前端应用状态的设计模式，专注于解决数据流的单向性问题。它由多个部分组成：Dispatcher、Store、Action 和 View。React 框架的开发者 Facebook 提出并推广了 Flux。

其优点在于具有明确的单向数据流，数据的流动路径清晰，易于追踪状态变化，从 Action 发起，经过 Dispatcher 分发到 Store，再由 Store 更新后通知视图，这样的流程使得状态变化一目了然，方便调试。例如在一个任务管理应用中，当用户点击 “添加任务” 按钮（触发 Action），Action 被 Dispatcher 分发到 Store，Store 更新任务列表数据后，视图自动更新显示新添加的任务，整个过程清晰可追溯。并且避免了深层次的嵌套状态传递，减少了因多层嵌套导致的数据传递混乱问题，还可以方便地实现时间旅行调试（Time Travel Debugging），能够回溯应用的状态变化过程，有助于查找问题。

但 Flux 也存在一些不足，初始学习曲线较陡峭，开发者需要理解其概念和工作原理，包括各个组件的作用和协作方式。对于简单应用可能显得过于繁琐，因为其架构相对复杂，在简单场景下可能会增加不必要的代码量。

在使用 React 框架时，开发者可以结合 Redux（一个 Flux 的实现）来管理应用状态。Reducer 充当 Store，Action 负责描述状态变化，而视图组件则负责订阅状态并渲染。例如：

// 定义 Action 类型
const ADD_TODO = 'ADD_TODO';
const TOGGLE_TODO = 'TOGGLE_TODO';

// Action 创建函数
function addTodo(text) {
  return {
    type: ADD_TODO,
    text,
  };
}

function toggleTodo(index) {
  return {
    type: TOGGLE_TODO,
    index,
  };
}

// Reducer
const initialState = {
  todos: [],
};

function todoReducer(state = initialState, action) {
  switch (action.type) {
    case ADD_TODO:
      return {
      ...state,
        todos: [...state.todos, { text: action.text, completed: false }],
      };
    case TOGGLE_TODO:
      return {
      ...state,
        todos: state.todos.map((todo, i) =>
          i === action.index? {...todo, completed:!todo.completed } : todo
        ),
      };
    default:
      return state;
  }
}

export default todoReducer;

这里的 todoReducer 作为 Redux 中的 Reducer，根据不同的 Action 类型（addTodo 和 toggleTodo 产生的 Action）对状态（任务列表状态）进行更新操作。

再比如一个社交应用中的点赞功能：

// 定义 Action 类型
const LIKE_POST = 'LIKE_POST';
const UNLIKE_POST = 'UNLIKE_POST';

// Action 创建函数
function likePost(postId) {
  return {
    type: LIKE_POST,
    postId,
  };
}

function unlikePost(postId) {
    return {
      type: UNLIKE_POST,
      postId,
    };
  }

// Reducer
const initialState = {
  posts: [],
};

function postReducer(state = initialState, action) {
  switch (action.type) {
    case LIKE_POST:
      return {
      ...state,
        posts: state.posts.map(post =>
          post.id === action.postId? {...post, likes: post.likes + 1 } : post
        ),
      };
    case UNLIKE_POST:
      return {
      ...state,
        posts: state.posts.map(post =>
          post.id === action.postId? {...post, likes: post.likes - 1 } : post
        ),
      };
    default:
      return state;
  }
}

export default postReducer;

此 postReducer 负责处理点赞和取消点赞操作对应的状态更新，清晰地展示了 Flux 模式在处理特定功能时的状态管理流程。

4. Component - Based

基于组件的设计模式是一种将应用拆分为多个独立可复用的组件的方式。这种模式在现代前端框架中被广泛采用，比如 React、Vue.js 和 Angular。

基于组件设计模式的优点突出，它增强了代码的可维护性和可复用性。每个组件都是独立的功能单元，可以在不同项目或同一项目的不同部分重复使用，例如一个按钮组件可以在多个页面的不同场景下使用。拆分成小块的组件易于理解和测试，开发人员可以单独对组件进行功能测试和优化。而且可以提高开发效率，多人协作更加流畅，不同开发人员可以负责不同组件的开发工作。

不过，过度拆分可能导致组件层级复杂，影响性能，过多的组件层级可能会增加渲染的开销和代码的执行路径长度。组件之间通信可能需要额外的工作，尤其在多层级嵌套时，跨层级组件通信可能需要借助特定的通信机制，如 React 中的 Prop Drilling 或者使用状态管理库来实现。

在 React 中，组件是构建界面的基本单元。以下是一个简单的 React 组件的示例：

import React, { Component } from'react';

class Counter extends Component {
  constructor(props) {
    super(props);
    this.state = { count: 0 };
  }

  increment = () => {
    this.setState({ count: this.state.count + 1 });
  };

  render() {
    return (
      <div>
        <p>Count: {this.state.count}</p>
        <button onClick={this.increment}>Increment</button>
      </div>
    );
  }
}

export default Counter;

此 Counter 组件具有自己的状态和交互逻辑，可独立使用或组合到更大的应用中。

再看一个导航栏组件的案例：

import React, { Component } from'react';
import { Link } from'react-router-dom';

class Navbar extends Component {
  constructor(props) {
    super(props);
    this.state = {
      isLoggedIn: false,
    };
  }

  handleLogin = () => {
    // 模拟登录操作，这里可以添加实际的登录逻辑
    this.setState({ isLoggedIn: true });
  };

  handleLogout = () => {
    // 模拟注销操作，这里可以添加实际的注销逻辑
    this.setState({ isLoggedIn: false });
  };

  render() {
    return (
      <nav>
        <Link to="/">Home</Link>
        {this.state.isLoggedIn? (
          <button onClick={this.handleLogout}>Logout</button>
        ) : (
          <button onClick={this.handleLogin}>Login</button>
        )}
      </nav>
    );
  }
}

export default Navbar;

这个 Navbar 组件可以在多个页面中复用，根据用户的登录状态显示不同的按钮，并且可以通过点击按钮触发相应的登录或注销逻辑操作。

还有一个卡片组件的示例：

收起

javascript

复制

import React, { Component } from'react';

class Card extends Component {
  constructor(props) {
    super(props);
    this.state = {
      isFlipped: false,
    };
  }

  handleFlip = () => {
    this.setState({ isFlipped:!this.state.isFlipped });
  };

  render() {
    const { title, content } = this.props;
    return (
      <div className={`card ${this.state.isFlipped? 'flipped' : ''}`} onClick={this.handleFlip}>
        <div className="card-front">
          <h3>{title}</h3>
        </div>
        <div className="card-back">
          <p>{content}</p>
        </div>
      </div>
    );
  }
}

export default Card;

该 Card 组件可以用来展示信息，并且通过点击卡片可以翻转显示更多内容，可在各种需要展示卡片式信息的地方复用，如产品展示、信息列表等场景。

总结
在前端框架中，设计模式是构建高质量应用的重要组成部分。MVC 和 MVVM 模式有助于分离关注点，使开发分工明确、逻辑清晰；Flux 模式解决了状态管理问题，让数据流有序可控；而基于组件的设计模式提高了代码的可维护性和复用性，提升开发效率。选择适合项目需求的设计模式，并在实际应用中合理运用，可以帮助开发者构建出更具可扩展性、稳定性和可维护性的前端应用。无论是选择经典模式还是现代模式，关键在于根据项目的规模和特点做出明智的决策，充分发挥各设计模式的优势，规避其劣势，从而打造出优质的前端项目。

前端框架中的设计模式 青训营X豆包MarsCode 技术训练营AI｜ 豆包MarsCode AI 刷题

1. MVC（Model - View - Controller）

2. MVVM（Model - View - ViewModel）

3. Flux

4. Component - Based

前端框架中的设计模式青训营X豆包MarsCode 技术训练营AI｜豆包MarsCode AI 刷题