Php 存储库模式与ORM

当您有ORM时，存储库模式有什么好处

例如。假设我有以下（虚构的）表格：

表格：用户

pk_user_id
fk_userrole_id
username

fk_userrole_id
role

表格：用户角色

pk_user_id
fk_userrole_id
username

fk_userrole_id
role

现在使用orm，我可以简单地将其放入模型文件中：

$user = ORM::load('users', $id);

现在$user已经是我的对象，可以很容易地延迟加载：

（如果事情自动单数化/复数化，那就更好了）

---

现在使用Repository模式，我必须为用户和角色创建一个存储库。存储库还需要各种函数来为我检索和存储数据。此外，它还需要使用实体模型。所以我也必须创造所有这些

对我来说，这看起来像是很多事情要做。。。当我可以简单地用ORM获取上面描述的数据时。我可以很容易地存储它：

ORM：：存储（$user）

在这种情况下，它不仅将用户对象存储到数据库中，还将存储我对“角色”对象所做的任何更改。因此，不需要像存储库模式那样进行任何额外的工作

---

---

所以我的问题基本上是，为什么我要将存储库模式与ORM一起使用？我已经看到了在哪里使用该模式的教程（如Doctrine）。但这对我来说真的没有任何意义。。。任何人都可以解释它与ORM结合使用的原因。

ORM是存储库的一个实现细节。ORM只是使以OOP友好的方式访问db表变得容易。就这样

存储库抽象持久性访问，无论它是什么存储。这就是它的目的。使用db或xml文件或ORM并不重要。存储库允许应用程序的其余部分忽略持久性细节。通过这种方式，您可以通过模拟或存根轻松测试应用程序，如果需要，您可以更改存储。今天您可能会使用MySql，明天您可能会希望使用NoSql或云存储。用ORM做那件事

存储库处理域/业务对象（从应用程序的角度来看），ORM处理db对象。业务对象不是db对象，第一个是行为，第二个是美化的DTO，它只保存数据

编辑 您可能会说，存储库和ORM都是对数据的抽象访问，然而，问题在于细节。存储库抽象出对所有存储关注点的访问，而ORM抽象出对特定RDBMS的访问

简而言之，存储库和ORM有不同的用途，正如我前面所说的，ORM始终是回购协议的一个实现细节

---

您还可以查看有关存储库模式的更多详细信息。

ORM和存储库模式…取决于设置。

如果使用ORM实体作为域层，请不要使用存储库

如果您有一个单独的域模型，并且需要从该模型映射到ORM实体并执行保存，那么存储库就是您所需要的

您可以找到更多详细信息（但必须登录到链接中）。另外，要了解差异，请查看存储库模式的

大多数人使用他们称之为存储库的类，但它们根本不是存储库，只是查询类——如果您决定使用#1选项，这就是您应该放置查询的方式/位置（参见上面的答案）。在这种情况下，请确保不要从该查询类中公开DbContext或ISession，也不要从那里公开CUD方法-记住，查询类

#2选项很难选择。如果使用真实的存储库，存储库界面上的所有输入和输出都将包含清晰的域类（并且没有与数据库相关的对象）。禁止从那里公开ORM映射类或ORM架构相关对象。还有一个保存方法。这些存储库可能还包含查询，但与查询类不同，这些repo将做更多的事情——它们将获取您的域聚合（集合和实体树），并通过将这些类映射到ORM类并在ORM上执行保存，将它们保存到DB。这种样式（#2）不需要使用ORM，存储库模式主要是为ADO.NET（任何类型的数据访问）创建的

无论如何，这两个选项是我们可以做的两个极端很多人使用ORM存储库，但他们只是添加了一层额外的代码，没有真正的功能，唯一真正的功能是类似查询类的行为

---

另外，当有人谈论工作单元时，我会很小心，尤其是在使用ORM时。几乎互联网上的每一个样本在架构方面都是失败的。如果您需要UoW，为什么不使用TransactionScope（只需确保您有一个包装器，默认情况下使用的不是可序列化事务）。在99.9%的情况下，您将不需要管理2组独立的数据更改（因此2组OuW），因此TransactionScope将是.NET中的一个好工具-对于PHP，我将寻找一些开放会话视图实现…

ORM是一种反模式。我不能说我真的同意那个帖子。尤其是在现代社会。它为你懒散地加载关系，你可以很容易地指定你想要什么颜色（如果你需要）。@w00在你看来，你并不孤单。。。有关存储库作为反模式的一些讨论，请参见此处：