在大多数框架中，您都有表示数据库中行的模型类。
例如php代码:
class User extends Model {}
我给了 Laravel Eloquent 例子，但这对大多数 php 框架都是正确的。
然后在类中添加关系:
public function pictures()
{
return $this->hasMany('App\Picture');
}
然后你添加一些这样的方法:
public function deleteComments()
{
// delete comments code here
}
我的第一个问题是:这是好的设计架构吗，因为多年后当项目变大时，您将与用户建立许多关系(图片、评论、帖子、订阅等)。 该类可能会变成 10k 行左右的代码。
那样的话，类会变得非常庞大，难以维护。 此外，单一责任原则可能会被违反，因为您在一个类中有太多方法。
此外，如果我想在另一个应用程序中使用该类，我不能，因为我还必须在第二个应用程序(网站)中提取图片、评论等。
如果我制作其他类，如“UserPictures”、“UserPictureDeleter”，代码将变得更加复杂。
这也是一种很好的做法吗？如果不是，您对如何使代码不因方法过多而变得臃肿而易于使用有什么建议吗？
您是否同意所有这些方法都属于 User 类？
最佳答案
Laravel 和其他一些框架提供 Active Record在他们的模型基类中的概念。 Active Record 的主要思想是将表行表示为一个对象，其中包括行的数据和使用数据库的方法。
在小型简单应用程序中使用 Active Record 模式是完全合理的，因为这种模式提供了快速开发应用程序的能力。但是如果你的应用程序有很多代码和困难的业务逻辑，Active Record 会给你的应用程序架构带来很多问题。 Active Record 会产生以下问题:
- 违反单一职责原则，导致代码臃肿。 Active Record 总是违反这个原则，因为它总是有两个职责:它实现业务逻辑和数据库工作的方法
- 违反低耦合原则 (GRASP)，使代码重用更加困难
- 如果您使用 Active Record 模式，则很难创建合格的抽象
这些问题的解决方案是使用 OOP 抽象而不是使用表行抽象。例如，您可以使用 Domain Model和 Domain-driven design .对于大型应用程序，这种方法优于 Active Record 模式。
不幸的是，这些概念篇幅太大，无法在本文中进行解释，但您可以阅读 Eric Evans 的“领域驱动设计”。这是一本关于应用程序设计的好书。此外，您可以在 google 中找到许多关于这些概念的文章。例如Building a Domain Model , Implementing Domain-Driven Design in PHP (拉维尔)
关于php - 大型应用ActiveRecord的设计问题，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/53348905/