Design patterns 是一个类，它封装了对象如何与中介（而不是外观）交互的逻辑

一个类的目的是提供数据（假设它提供

Student

s）和客户机代码如下：

students = StudentProvider.getAllStudents()

其底层实现将使用

RemoteStudentRepository

实例封装从远程服务器检索

Student

，然后使用

LocalStudentRepository

实例将其保存到本地：

// StudentProvider#getAllStudents()
students = remoteStudentRepo.GetAll((students) => {
   // Callback with a list of students as a parameter

   for student in students {
       localStudentRepo.updateOrInsert(student);
   }
});

return students;

我知道Facade是结构化的，而Mediator是行为的，因此我认为这是一个Mediator示例，因为它封装了对象交互的逻辑（远程获取和本地存储），但我不确定这是否是“添加的功能”足以称之为调解人

---

那么它是什么呢？

我认为它既不是一个门面，也不是一个调解人。从技术上讲，它可能有一种独特的成分，你可以在前一种中找到。然而，不要被诱导性地称之为设计模式，因为它并不能解决相关的问题。现在它只是一个耦合到另一个类的类

Facade为子系统的接口提供了统一的接口。在您的示例中，“StudentProvider”并不一定旨在消除“remoteStudentRepo”的使用。如果它真的这样做了，那么这不是一个复杂的子系统，也没有多个接口需要统一

中介器使对象明确地相互引用。它有助于分离组件，但仍然允许它们一起工作。再一次，在我们的情况下，情况不一样

如果它不能解决相同的问题，它就不是相同的模式

---

---

顺便说一下，@MikeSW是对的。您的示例违反了命令查询分离（）原则。方法应该是一个查询或一个改变状态的命令。查询是幂等的。

这是错误的代码。您有一个

get

，它会在数据库中增加…的可能重复项