Laravel 中的模型继承 [英] Model Inheritance in Laravel

问题描述

我目前正在与 Laravel 合作，我正在努力解决每个模型都需要从 Eloquent 扩展的事实，我不确定如何实现模型层次结构(使用不同的表)

i'm currently working with Laravel and I'm struggling with the fact that every model needs to extend from Eloquent and I'm not sure how to implement a model Hierarchy (with different tables)

例如:

假设我有一个抽象模型 Tool，然后是一个模型 Hammer 和一个从 Tool 扩展的模型 Screwdriver.

Let's say I have an abstract model Tool, and then a Model Hammer and a Model Screwdriver that extend from Tool.

现在，Tool 将扩展 Eloquent ...但是，没有用于工具的表，有一个用于锤子的表和另一个用于螺丝刀的表，因为它们具有不同的属性.

Now, Tool would extend Eloquent ... BUT, there is NO Table for Tools, there is a table for Hammers and another Table for Screwdrivers, because they have different attributes.

当它们都扩展 Tool 时，我如何指定 Hammer 有一张桌子，Screwdriver 有一张桌子?以及如何使用 Eloquent 调用例如所有工具?

How do I specify that Hammer has a table and Screwdriver has a table when they both extend Tool? And how can I use Eloquent to call, For Example, All Tools?

喜欢:

Tools::all()

这应该带上所有的锤子和螺丝刀，因为它们都是工具

This Should bring all Hammers and Screwdrivers because they are all Tools

这可以使用 Eloquent 吗?

Is this possible using Eloquent?

推荐答案

尽管我喜欢多态关系 (PR) 方法比单表继承 (STI)，感觉还不是真正的继承方式.从领域(例如 UML 类图)的角度来看，这就像尝试使用组合关系而不是继承.

Even though I like the Polymorphic Relations (PR) approach slightly better than the Single Table Inheritance (STI), it still does not feel anything like a true inheritance approach. From the domain (e.g. a UML Class Diagram) point of view, it is like trying to use a composition relationship instead of inheritance.

从数据库一致性的角度来看，多态关系本身在 Laravel 中已经是一个非常奇怪的解决方案(恕我直言).由于不能有单个字段作为多个表的外键，这可能会导致加入不应加入的 ID.以及不遵守的逆关系.

From a database consistency point of view the polymorphic relation by itself is already a very weird solution in Laravel (IMHO). As there can be no single field that is a foreign key to multiple tables, this can lead to joining ID's that should not be joined. And inverse relationships that are not obeyed.

虽然我实际上并不是在描述问题的解决方案，但我会提出一种与 PR 和 STI 不同的方法.该解决方案类似于 Hibernate 的 table-per-subclass 方法.我认为 Dauce 对 Eloquent 的扩展 正朝着相同的方向发展，只是似乎仍然存在一些实现问题.

Although I'm not actually describing a solution to the problem, I'd propose a different approach than PR and STI. This solution would be similar to Hibernate's table-per-subclass approach. I think that Dauce's extension to Eloquent is going in the same direction, except there seem to be a few implementation issues still.

从数据库的角度来看，每个子类的表也意味着超类包含每个直接子类的一列.然后您可以将外键约束放在(非空)id 上并正确使用这些关系.但是，Laravel 的神奇 Eloquent 类中仍然应该有一些额外的逻辑可以将请求的对象转换为正确的类型.

From a database point of view, a table per subclass would also mean that the super-class contains one column per direct subclass. Then you can put foreign key constraints on the (non-null) id's and properly use the relationships. However, there should still be some extra logic in Laravel's magic Eloquent class that turns the requested object into the right type.

所以对我来说，在功能上，Eloquent 模型应该在 PHP 端正确继承，而数据库仍然可以使用外键约束.

So for me, functionally, the Eloquent models should properly inherit on the PHP side, while the database can still use the foreign key constraints.

这篇关于Laravel 中的模型继承的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！