具有多个持久层的PHP数据映射器

我正在用PHP编写一个必须写入三个持久层的系统：

• 一个web服务
• 两个数据库（一个mysql一个mssql）

原因是遗留系统，无法更改

我希望使用DataMapper模式，并且我正在尝试建立实现我想要的最佳方式。我有一个如下的界面：

为了简洁起见，下面是一些精心设计的精简代码：

我的问题是，因为有三个持久层，所以每个持久层也可能需要三个映射器。我想一个干净的设计模式启发界面，使这项工作

我认为它有三个选择：

向服务中注入三个映射器，并在每个映射器上调用create

$\映射器是一个数组/集合，它在每个数组/集合上调用create进行迭代

$\映射器实际上是一个容器对象，充当 在每个服务器上创建更多代理和调用

---

我觉得这些解决方案中的每一个都有问题，如果有任何反馈/认可的设计模式符合这一点，我将不胜感激。

我不得不解决一个类似的问题，但在很多年前的PEAR DB时代。在这种情况下，需要跨多个数据库复制数据

我们不存在不同数据库具有不同映射的问题，尽管这样比较简单

我们所做的是虚化DB类并重写getResult函数（或调用它的任何函数）。然后，这个函数分析SQL，如果它是读的，它将只发送给一个备份的SQL，如果它是写的，它将发送给所有备份的SQL

对于一个使用率非常高的站点来说，这实际上非常有效

在这种背景下，我建议将所有持久性操作全部facading。一旦您这样做了，实现细节就不再那么重要，可以随时更改

从这个角度来看，您的任何实现想法似乎都是合理的方法。不过，你会想考虑很多事情

• 如果其中一个后端抛出错误怎么办
• 写入三台数据库服务器对性能有什么影响
• 写入是否可以异步完成（如果是，请再次询问第一个问题）

还有另一种可能的方法来解决这个问题。即使用存储过程。如果您有一个主数据库服务器，您可以编写一个触发器，在提交时（或大约提交时）连接到另一个数据库并同步数据

如果不需要立即进行数据更新，则可以让主数据库记录更改，并让另一个脚本定期将此数据“馈送”到其他系统中。同样，需要考虑错误问题

---

希望这有帮助。

我认为选项2是最好的。我会同意的。如果您有10个以上的映射器，那么选项3将把创建逻辑转移到映射器本身是有意义的，但是由于您有一个合理数量的映射器，因此只需注入它们并在其上迭代就更有意义。通过添加另一个映射器来扩展功能只需在依赖项注入配置中添加一行即可。

首先，一点术语：您所谓的三层实际上是三个模块，而不是层。也就是说，持久层中有三个模块

现在，这个问题的基本前提是：必须有三种不同的持久性逻辑，对应于三种不同的存储源。这是你无法避免的。因此，问题只是关于如何在这个模块上调用write操作（假设对于read，您不需要全部调用这三个，或者如果您这样做，这是一个单独的问题）

从你列出的三个选项中，我认为第一个更好。因为，这是三者中最简单的一个。另外两个仍然需要分别调用三个模块，另外还要引入一个容器或某种数据结构。您仍然无法避免在某处调用三个模块

如果使用第一个选项，那么显然需要使用接口，为用户/客户机（在本例中为服务）提供统一的抽象

我的观点是： 1.它们是您问题中固有的复杂性，您无法进一步简化。 2.第一种选择更好，因为另外两种选择使事情变得更复杂，而不是简单