Question

我一直无法在以下情况下找到合适的设计模式：

我正在使用PHP-Activerecord编程MVC，并使用基于SOAP的SOA在企业环境中编写自定义框架。现在，我正在尝试在不同的访问层上基本上访问和/或保持相同的实体，具体取决于具体情况。为了更加重要，我将选择一个例子：

我们的系统中有一个“会员”实体。现在，访问此成员的一种方法是通过SOAP Web服务，我已经编写了一个抽象程序：

class Member extends ServiceAbstractor {}

Pro：实时访问数据（我无法直接访问生产数据库）。

Con：相当缓慢，由于我无法改变的架构，我不能轻易地与其他实体或“SELECT LIKE'％member1％'”进行“JOIN”这样的事情。

另一种方法是通过较旧的数据库复制访问同一实体。为此我会使用这样的语法：

class Member extends ActiveRecord\Model { /* Connection 1 */ }

Pro：非常快，我可以完成上述所有花哨的工作，使用SQL对成员数据进行过滤，报告和聚合。

Con：只读，数据有点旧（但对大多数应用来说并不重要）。

有时候，我甚至需要在会员上存储额外的元数据，例如谁更改了某些内容。

为此我会使用本地MySQL数据库，也使用ActiveRecord，但是使用不同的连接：

class Member extends ActiveRecord\Model { /* Connection 2 */ }

现在我基本上喜欢在逻辑视角中使用相同的实体“Member”，但显然我不能从三个不同的访问层继承同一个类。

可能的用例：通过数据库副本（SELECT LIKE）中的部分名称搜索获取成员ID，然后从Web服务获取“真实”成员，使用某些内容进行更新，然后存储编辑器并对此进行最后更改我本地数据库中的成员。

现在我可以将各自的类命名为“Member”，“MemberCopy”和“MemberMeta”（？），但这让我有点不满意，因为我认为我在这里谈论的是同一个实体。

是否有人对此问题的命名或设计模式有类似的问题和/或一些建议？

Answer 1

如何使用逻辑普通和简单类Member（因此不是实体对象）和三个不同的DAO类（一个用于WS，一个用于复制数据库，其余用于本地数据库）作为输入并返回逻辑Member对象？