laravel - 简化存储库模式和SOA的实现

Question

我正在使用Laravel 5，但我认为这个问题可以应用到单一框架或语言的范围之外。最近几天，我一直致力于编写存储库的接口和实现，然后将服务绑定到IoC和所有其他东西。感觉非常慢。

如果我在服务中需要一个新方法，例如Store::getReviews()，我必须在我的实体模型类（数据源，在这种情况下为Eloquent）中创建关系，那么我必须在repo接口中声明该方法，以使其对于任何其他实现，那么我必须在repo实现中编写实际的方法，然后我必须在服务上创建另一个方法，该方法调用该repo来提取商店的所有评论...（有意使用的句子）太多了。

现在，创建新模型不再像扩展基础模型类那样简单。我必须编写并跟踪许多文件。有时，我对于应该在哪里放置什么东西会感到困惑，或者在建立一个我在错误的类中的方法时发现中途。我还在服务中丢失了Eloquent的查询构建。每当我需要Eloquent拥有的东西时，就必须在存储库和服务中实现它。

该体系结构背后的想法很棒，但是我发现实际的实现非常繁琐。有没有更好，更快的做事方法？即使我将通用方法和东西放在抽象类中，我也觉得自己太混乱了。有太多要写的东西。

Answer 1

当我搬到Laravel 5时，我已经为所有这些东西而苦恼。那是我决定更改方法（it was tough decision）的时候。在此过程中，我得出以下结论：


我决定删除Eloquent（和Active Record模式）。我什至不使用查询生成器。我仍然使用DB fascade，因为它很方便进行参数化查询绑定，事务，日志记录等操作。开发人员应该了解SQL，如果需要了解SQL，那么为什么还要在它们上施加另一层抽象（无法完全或有效替换SQL的层）。记住，从OOP世界到Relational Database世界的桥梁永远都不会很漂亮。忍受我，继续阅读...
由于＃1，我切换到Lumen，其中Eloquent默认情况下处于关闭状态。它快速，精简，仍然可以完成Laravel中我需要和喜爱的一切。
每个查询都属于以下两种类别之一（我想这是CQRS的一种形式）：

3.1。存储库（命令）：这些存储库用于处理状态更改（写入）以及需要对对象进行水化处理并在更改状态之前应用一些规则的情况（有时必须进行一些读取才能进行写入）（有时还需要进行批量写入，水合可能效率不高，因此只需创建也可以执行此操作的存储库方法即可。因此，我有一个名为“域”的文件夹（用于域驱动设计），里面有更多文件夹，每个文件夹代表我对业务领域的看法。对于每个实体，我都有一个配对的存储库。这里的实体是一个类似于其他人称为“模型”的类，它拥有属性，并具有可帮助我保持属性有效或对其进行处理的方法，这些方法最终将保留在存储库中。存储库是一个带有一堆方法的类，这些方法代表了我需要做的与该实体相关的所有查询类型（即$repo->save()）。这些方法可以接受一些参数（以允许在内部进行一些动态查询操作，但又不要过多），在内部您可以找到原始查询和一些用于混合实体的代码。您会发现存储库通常接受和/或返回实体。

3.2。查询（也称为屏幕？）：我有一个名为“查询”的文件夹，在其中有不同类的方法，这些方法内部具有用于执行显示工作的原始查询。这些类只是有助于将事物组合在一起，但与存储库不同（即，它们不执行混合，写入，返回实体等操作）。目标是将它们用于读取和大多数显示目的。
不要这样不必要地进行交互。接口非常适合需要它们的多态情况。您知道要在多个实现之间进行切换的情况。当您以1：1的比例工作时，它们是多余的工作。另外，很容易上一堂课，以后再把它变成一个接口。您永远都不会过早优化。
由于＃4，您不需要很多服务提供商。我认为为我的所有存储库都配备服务提供商可能会过大。
如果您想关闭数据库引擎时几乎是神话般的时刻，那么您要做的就是去两个地方。上面＃3中提到的两个地方。您替换内部的原始查询。这很好，因为您可以列出应用程序所需的所有持久性方法。您可以在这些方法中定制每个原始查询，以便以数据存储所要求的独特方式使用新的数据存储。该方法保持不变，但是内部查询已更改。重要的是要记住，更改数据库所需的工作显然会随着您的应用程序的增长而增长，但是应用程序的复杂性必须到位。每个原始查询代表复杂性。但是，您已经封装了这些原始查询，因此已尽力保护了应用程序的其余部分！


我成功地使用了受DDD概念启发的这种方法。一旦使用了存储库方法，则几乎不需要使用Eloquent IMHO。而且我发现我没有写多余的东西（正如您在问题中提到的），同时仍然保持我的应用程序灵活以适应将来的更改。这是另一个来自工匠的approach（尽管我不一定同意使用Doctrine ORM）。祝你好运，编码愉快！