【发布时间】:2018-12-12 18:43:00
【问题描述】:
我想使用服务层。但有一些问题。我将提供示例并让我们讨论它。
假设在控制器存储函数中,我编写了错误代码,例如我在那里进行了验证,我在那里也有模型,给这个模型用户输入的属性并存储它。基本上我把所有东西都放在一个控制器里,这会导致胖控制器。现在,我们可以做两件事来解决这个问题。
1) 将验证逻辑移动到验证类(简单),然后我们在其中创建新模型实例并为其设置属性并将其存储在数据库中(该逻辑现在在控制器中,但我们将其带到模型中)。这样每当我们需要在另一个地方使用相同的东西时,我们就可以调用这个模型的函数。如果我们没有这样做,我们会一遍又一遍地重复这个逻辑。业务逻辑呢?让我们以服务层中的业务逻辑为例。之后我们的控制器将如下所示:
public function store(Request $request)
{
DB::beginTransaction();
try{
$results = $this->transport_service->doLogic($request); //makes logic according to user data.
if($results) {
$storeData = Transport::storeTransportThisWay($results, $request); //then we use model's function..
}
DB::commit();
return response()->json(['success'=>'Transport type has been binded to column and its values successfully'], 200);
}catch(\Exception $e){
DB::rollback();
return response()->json(['error'=>'Something went wrong, please try later.'], 500);
}
}
所以基本上,我在模型中编写任何类型的查询。以及服务中的任何类型的业务逻辑。
第一个问题是:这是一个好方法吗?
2) 我们可以做的是在控制器中,让我们调用服务的方法来编写查询和业务逻辑。这是每个人都使用的方式。但问题是如果我遵循这种方法,比方说在服务的一种方法中,我写了一个查询和业务逻辑。一切正常。但假设在另一个我也需要有相同的查询,但我不需要那个业务逻辑。问题是我不能使用该服务的方法,因为它既有业务逻辑又有查询,我只需要查询。所以问题是我还必须将查询放在其他地方,但不是在服务的方法中,这给了我们另一个问题,将查询放在哪里。 我说的对吗?如果是,我的问题是为什么人们喜欢这种方法,为什么不喜欢我提到的第一种方法?
将不胜感激。
【问题讨论】:
-
嗨,你可以在这里看到我的答案stackoverflow.com/a/53770712/3738542,这就是我对 go 设计的看法,但我相信同样的原则也适用于 php
标签: php laravel model-view-controller design-patterns