php – 业务逻辑应该与模型分开吗？

2023年6月16日 220次阅读

我们正在开发一个代码相当重的
PHP5项目,在上周我开发了一个RESTful API的PoC.我们将模型类与业务类分离.

我发现,尝试实现CRUD功能,直接针对模型实现CRUD非常简单,而针对业务逻辑实现CRUD则不是,因为它的功能特定于当前存在的视图,并且其接口不提供我需要实现API的通用数据访问模型.

考虑到这一点,我想到了以下问题：

>与数据交互的最佳方式是什么,保持模型的灵活性并保持模型当前不关心的功能(比如在更改电子邮件地址时发送带有激活链接的邮件)？
>以前在django中工作很多,大多数业务逻辑都在模型中实现,为什么要保持业务逻辑分离？你有任何现实生活中的例子吗？如果有的话,这会解决什么问题？

我也想到了一些可能的解决方案：

>将整个业务逻辑放入模型中.检查在调用save方法之后/之前更改了哪些字段.
>使用观察者模式通知业务对象模型中的更改并直接与模型交互.

你认为有什么利弊,你会做什么？

最佳答案 如果您将数据存储在数据访问层中,则可以获得所需的分离以及模型中的功能：

DAL (doing queries etc)
  |
Model (doing business)
  |
Controller
  |
View

所以在视图中你有一个动作：标记为付费.因此,您的控制器获取请求(POST)/ invoice / 1 / markaspaid(或您使用的任何其他URL结构).然后控制器调用模型：

$Invoice=new Invoice();
$Invoice->markAsPaid(1);

然后您的模型调用DAL来实际存储此更改.没有必要将其与模型分开.如果它非常复杂或非常复杂,您可能会考虑为复杂任务提供单独的服务.这样你的模型变得更薄,复杂的部分变得分离.

What is the best way to interact with the data, keeping the
flexibility of the model and keeping the functionality the model
doesn’t care about at the moment (like sending a mail with an
activation link when changing the email address)?

我完全不理解这一点.据我所知,你应该将发送电子邮件进程与正常的代码运行分开.所以把它放在队列中然后找到它.它不是您正常代码路径的一部分.您可以从模型中启动它,但这是关于它的.

请参阅此问题,其中包含有关该主题的相关信息：
Cakephp cron job to call a controller’s action

点赞