6

我们正在开发一个代码量很大的 PHP5 项目，上周我研究了一个 RESTful API 的 PoC。我们将模型类与业务类分开。

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

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

  • 与数据交互、保持模型的灵活性并保持模型目前不关心的功能（例如在更改电子邮件地址时发送带有激活链接的邮件）的最佳方式是什么？

  • 之前用 django 工作了很多，大部分业务逻辑都是在模型中实现的，为什么还要保持业务逻辑分开呢？你有现实生活中的例子吗？如果有的话，这能解决什么问题？

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

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

在你看来有什么好处和坏处，你会怎么做？

4

1 回答 1

2

如果您将数据存储分离为数据访问层，您将获得所需的分离和模型中的功能：

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

因此，在视图中您有一个操作：标记为已付款。因此，您的控制器获取请求 (POST) /invoice/1/markaspaid （或您使用的任何其他 url 结构）。然后控制器调用模型：

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

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

与数据交互、保持模型的灵活性并保持模型目前不关心的功能（例如在更改电子邮件地址时发送带有激活链接的邮件）的最佳方式是什么？

我完全不明白这一点。据我所知，您应该将发送电子邮件过程与您的正常代码运行分开。所以把它放在一个队列中，然后在那里找到它。它不是您正常代码路径的一部分。您可以从您的模型中启动它，但仅此而已。

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

于 2012-07-21T11:24:11.910 回答