大家好 我想向您坦白，并向您介绍在Laravel上进行开发时的感受。 不，不用考虑它，我喜欢这个框架，我非常感谢创建并支持它的团队，他们做得非常出色，我认为Laravel是Symfony的最佳延续，同样受到我的喜爱。
我喜欢愚蠢的代码。 愚蠢的意义是，即使十年后，如果客户要求您对其进行更改，即使在星期五参加公司聚会之后，您也可以在不深入整个逻辑的情况下做到这一点，而不会破坏旧代码。 从某种意义上来说，您无需付出任何认知上的努力就能理解它。 但是Laravel Eloquent ORM中有一种架构解决方案让我哭了。 有意思吗 来这只猫。
聪明的人很久以前就为我们准备了一切：OOP，设计模式，SOLID，DDD和其他令人恐惧的单词，这些单词一开始会吓到您，然后直截了当。
这些我喜欢Laravel和Symfony。 它们使您可以立即开出最笨拙，最安全的代码。 是的 它们每个都有其缺点。但是在Laravel中，有一个让我最烦恼的。 这是使用Active Record Pattern（AR）来处理模型。
对于初学者来说，有关此模式的一些知识。 这是怎么回事？ 为了理解，您应该去了解应用程序设计的主旋律-存储库模式。 此模式是一个集合。 通常可以在抽象存储位置中检索，修改，保存，删除实体的实体（Entity）的集合。 在100％的情况下，有90％的存储位置是各种数据库。 但是可能存在文件系统，某种缓存，甚至是外部API。
这种方法与共同责任原则和DDD方法完全一致。 此外，由于采用了这种方法，因此实现了弱连接-我们不在乎应用程序的存储方式如何；当我们想直接使用数据的对象表示形式时，我们可以使用Entity；当需要与存储库进行交互时，可以使用Repository。
但是Laravel决定采用AR的方式，当您需要快速制作原型时，AR无疑是很酷且非常方便的，但是当您需要与多个数据源进行交互并在系统中对其进行操作时，这将成为令人难以置信的头痛。
AR是一种将实体和存储库映射到一个模型的模式。 即，对象成为数据库中特定记录的表示。 还有...什么？ 这会导致什么？为什么如此烦人？
首先，我们违反了分担责任的相同原则-在一个地方使用存储库的逻辑，而在另一个地方使用实体的逻辑。 这很重要，因为在我的系统框架中，我不想通过调用链从对象表示形式的数据库中转移一条线。 我想通过模型。 我不该该如何证明，如何改变和坚持下去。 我需要拥有那些只允许您与模型而不是与数据库中的行进行交互的方法。
其次，我们不能（由于持久层-存储层-与实体层相连的事实），只能更改模型的存储位置。 是的，我们可以在配置中执行此操作，并在支持的数据库中为每个人立即对其进行更改。 或仅针对特定模型进行更改（所有这些，我们不会删除任何查询生成器方法，因为您无法摆脱基类方法），并且会在代码中遇到大量可能的错误，或者，如果有其他错误，请上帝禁止将支持（并且这种情况一直存在）。
第三。 我想测试我的实体。 我要该死，以确保所做的更改不会破坏我的业务逻辑。 而且，正如实践所示，在AR的情况下，您无法执行此操作，因为违反了单一责任的恶魔原则！ 虽然在这里我有点不屑一顾。 测试模型是可能的，只是...有点复杂。
但是，不可能不说这种模式的优点。 尽管它的全部优点是“快速，简单，毫不犹豫”。 通过合并逻辑上接近其动作并经常使用的两个模式，我们得到了一个方便的工具，可以稍微减少代码量（在复杂性的方向上，我们还记得“哑代码”吗？）。 它还允许您在MVP形成阶段摆脱不必要的问题，这是强制性的（实践表明，这种情况很少发生，但仍然如此），它计划进行重写。 这使您可以将思想从“我们怎么做”问题转移到“我们怎么做”问题，即摆脱有关技术的不必要问题，而转向业务逻辑。
多年来，使用Laravel Eloquent ORM得出了什么结论？ 主动记录邪恶的肉体？ 不，对于某些情况，这是最酷的工具，尤其是在编写简单应用程序或此类应用程序原型的阶段。 但是，当您的应用程序扩展并且您必须使用大量数据源，编写具有100％测试覆盖率的代码并开始出现大问题时，这是不可能完成的事情。
是的，正在发明新的芯片（ Trucker ？），但让我们继续吧。 但是我仍然希望从框架中获得更多自由，尤其是因为它对很多人来说是如此好！