我是Laravel的新手,正在研究一系列API端点,这些端点从各种数据库表中获取数据,转换和处理该数据,然后将其作为JSON响应返回。通过阅读文档,我正在努力决定我的处理/转换代码应该存在的地方。
我已经在routes / api.php中设置了我的路由,让它们指向一个Controller
子类,但是从这里开始有点模糊,因为我现在不打算使用Eloquent ORM。通常我会为每个数据库表生成Model
子类,并对这些子类进行Repository
调用并转换返回的数据,如下所示:
Route => Controller => Repository => Model
但是,在不使用Eloquent ORM或Model
范例的情况下,我应该将数据库查询代码和处理/转换数据所需的逻辑(业务逻辑)放在哪里?使用DB查询和逻辑使控制器变胖似乎是一个混乱的解决方案,但同时很多Laravel DB示例代码确实将逻辑放在Controller子类中。
以下是如何在没有Eloquent
的情况下设置项目的示例。
class OrderRecord
{
protected $id;
protected $createdAt;
public function __construct($id, $createdAt = null)
{
$this->id = $id;
$this->createdAt = $createdAt ?: date('d-m-Y H:i:s');
}
public function getID()
{
return $this->id;
}
...
}
class OrderRepository
{
public function find($id): OrderRecord
{
// Here goes your querying. StdClass will be returned in this case
// that will be used to create new record.
$row = DB::table('orders')->find($id);
if ($row) {
return (new OrderRecord($row->id, $row->created_at));
} else {
// If not found you can throw an exception or return null
// (return type should be ?OrderRecord then) depending on
// how you want to design your workflow with repositories.
...
}
}
...
}
您还可以通过在存储库中分离查询和映射来扩展此设计 - 您将拥有只知道如何检索/存储原始数据的Repository
类,并且您将拥有知道如何在记录中创建/检索原始数据的Mapper
类(并充当存储库将用于从查询结果生成记录对象的工厂)。如果业务逻辑也需要可以互换,那么您还可以从控制器中获取业务逻辑,并将其放入控制器可以使用的单独类中。
Here是一篇关于基于存储库的方法以及如何扩展它的优秀文章。
所以我会提供一种方法,我认为可以完成你的要求。在我开发的API中,我使用route/api.php
文件来创建API端点。其中每个都指向执行身份验证和请求验证的Controller
。然后Controller
调用Service
类来处理应用程序的所有业务逻辑,这些是真正繁重的部分。 Service
类调用Repository
,它实际上执行Model
更改和保存。
几年前我在另一个项目中看到了这个,并为我的项目模仿了它。代码流程如下所示。不确定它是否适合你,但我发现它非常整洁,并保持代码以逻辑方式组合在一起。
Route => Controller => Service => Repository => Model