PHP 设计模式工厂、存储库和...？答案

【问题标题】：PHP design patterns Factories, Repositories and...?PHP 设计模式工厂、存储库和...？
【发布时间】：2016-12-24 05:32:28
【问题描述】：

我们有用于创建复杂对象的工厂。（用于制作东西）

我们有用于查找它们的存储库。（找东西）

我们有什么来更新它们？（为了改变东西）

似乎是拼图中缺少的一块？我认为它不属于存储库，因为这破坏了单一责任......

【问题讨论】：

“更新”不是对对象本身执行的操作吗？还是您的意思是“更新”，例如“将现有对象的更改状态保留回数据存储区”？
您将更新对象，然后将更新的对象传递回存储库；无论您的 repo 是将对象保存在内存中还是数据库中，您仍将执行 $repo->save($object) 之类的操作
我们有存储库来保存对象（复杂与否）。持久性包括查找但也存储（新的或更新的）对象（以便以后查找）。

【解决方案1】：

更新实体（因此，数据库）属于存储库。存储库本身是数据库本身和程序之间的一个层。

因此，每个数据库操作都属于存储库。此外，存储库不能与数据库通信，它也可以有 XML、CSV 或 API 作为数据源。但这并不重要，因为您正在与存储库进行通信。存储库会处理之后发生的所有事情。

您只需将存储库更改为另一个，您的程序就可以正常运行，因为所有存储库都实现了相同的接口。你不再喜欢那个 MySQL 数据库，那个老式的 CSV 更好吗？只需替换使用过的存储库即可。

使用存储库查找条目只不过是 SELECT 语句，那么您为什么不使用它 UPDATE 或 DELETE 呢？

进一步阅读MSDN

在web.archive.org找到了很好的解释和例子

【讨论】：

不同意。如果您采用该逻辑“因此每个数据库操作都属于存储库”。你无法扩展。
为什么不能扩展？每个实体都有自己的存储库，因此您可以扩展实体的数量，从而增加您将使用的存储库的数量。
想想吧。抽象出数据库交互并不是存储库的唯一原因。它们是“用于获取事物的对象”......这也是工厂模式存在“用于创建复杂事物的对象”的原因。他们都可以从抽象出数据库逻辑中受益......不像你说的那样他们唯一的原因......
为什么没有“升级者”来更新具有复杂关系和条件的实体以进行更新...
@AndrewMcLagan 并非总是如此。工厂是一种方法，它将返回一个类的新实例。工厂方法可以在表中创建一个条目，但这不是强制性的。在我看来，如果工厂方法修改了数据库，那就有问题了。因为工厂做的比它应该做的多。 (SPOF)。

【解决方案2】：

我认为这取决于方法。

以 DDD 为例，您所说的是正确的。 Repository 应该负责添加、查找和删除，因为它适用于集合，但是有一个问题是为什么它应该能够更新单个对象。

可以做什么？我想我只会复制别人说的话，所以我会发布链接来回答：approach to removing save/update from repository

【讨论】：

->save($object) 上的有趣说明 ...完成后的书架。
它并没有真正更新。你说的是从集合中删除它并基本上添加新的;-) 例如，id 呢？它使情况过于复杂。
对象知道自己的 id 并且不会改变 - 但是，如果 repo 位于数据库之上并自动保持集合的状态，它可能会全部崩溃。
好的，如果对象知道它自己的 id，为什么我们首先要从架子上删除它？我知道在现实世界中要对一本书进行更改，我们实际上会从集合中取出它，进行一些更改并将其放回原处，但是在对象编程中，我们不必从任何地方实际删除它，当想要更新它。货架是一种抽象。或者 - “没有勺子”，正如沃卓斯基曾经告诉过你的那样 ;-)
编程中的任何事情都没有终极极端的结论。总有办法的”。这就是其中之一。如果您不确定，或者您有更适合您的架构的东西，那就去吧。