MVVM 是否违反了 DRY

Java

MVVM（Model-View-ViewModel）是一种软件架构模式，用于将用户界面（View）与业务逻辑（Model）分离，通过一个中间层（ViewModel）来进行数据绑定和交互。在MVVM中，View只负责显示数据和接收用户输入，ViewModel负责处理业务逻辑和数据操作，Model则是数据的来源和存储。

MVVM的设计目标是提高代码的可读性、可维护性和重用性。一般来说，MVVM是符合DRY原则（Don't Repeat Yourself）的，因为它将视图逻辑和业务逻辑分离，避免了重复编写相同的代码。然而，有时候在实践中，MVVM也可能违反DRY原则，下面将通过案例代码进行说明。

视图模型的重复代码

在MVVM中，视图模型（ViewModel）是连接视图和模型的桥梁，它负责将模型中的数据转换成视图可以显示的格式。通常情况下，一个视图对应一个视图模型，但在某些特定场景下，多个视图可能需要展示相同的数据格式。这时候，如果每个视图都有自己的视图模型，就会导致代码的重复。

例如，我们有一个学生信息管理系统，其中有两个视图：学生列表视图和学生详情视图。它们都需要展示学生的姓名、年龄和成绩。如果按照传统的MVVM方式，我们需要为每个视图都创建一个对应的视图模型，这样就会导致视图模型中的代码重复，违反了DRY原则。

Javascript
// 学生列表视图模型
class StudentListViewModel {
  constructor() {
    this.students = []; // 学生列表数据
    this.loadStudents(); // 加载学生数据
  }
  loadStudents() {
    // 从数据源中加载学生数据
    // ...
  }
  // 其他业务逻辑
}
// 学生详情视图模型
class StudentDetAIlViewModel {
  constructor() {
    this.student = {}; // 学生详情数据
    this.loadStudent(); // 加载学生数据
  }
  loadStudent() {
    // 从数据源中加载学生数据
    // ...
  }
  // 其他业务逻辑
}

在上面的代码中，我们可以看到loadStudents()和loadStudent()这两个方法非常相似，它们都是从数据源中加载学生数据。如果在两个视图模型中都有这样的方法，并且这些方法的逻辑是相同的，这就违反了DRY原则。

解决方案：抽象共享逻辑

为了避免在视图模型中重复编写相同的代码，我们可以将共享的逻辑提取出来，形成一个单独的模块或基类，然后让视图模型继承或使用这个模块或基类。

Javascript
// 数据加载模块
class DataLoader {
  loadStudents() {
    // 从数据源中加载学生数据
    // ...
  }
  // 其他加载数据的方法
}
// 学生列表视图模型
class StudentListViewModel extends DataLoader {
  constructor() {
    super();
    this.students = []; // 学生列表数据
    this.loadStudents(); // 加载学生数据
  }
  // 其他业务逻辑
}
// 学生详情视图模型
class StudentDetAIlViewModel extends DataLoader {
  constructor() {
    super();
    this.student = {}; // 学生详情数据
    this.loadStudents(); // 加载学生数据
  }
  // 其他业务逻辑
}

通过以上代码改进，我们将数据加载的逻辑抽象到了DataLoader类中，然后让视图模型继承DataLoader类，这样就避免了在视图模型中重复编写相同的代码。这样做不仅符合DRY原则，还提高了代码的可维护性和可读性。

在MVVM中，尽管有时候会出现视图模型中的重复代码，但我们可以通过抽象共享逻辑的方式来解决这个问题，从而保持MVVM的符合DRY原则的特性。抽象共享逻辑可以避免代码重复，提高代码的可维护性和可读性，同时也方便后续的扩展和修改。因此，MVVM并不一定违反DRY原则，取决于我们如何设计和组织代码。