php - 在 CodeIgniter 应用程序中实现服务层的正确方法

Question

下面是在 CodeIgniter 应用程序中实现服务层的两种方式。

第一种方法

1.send request to the controller 
2.calling service layer methods from controller
3.return processed result data set(D1) from service layer to controller 
4.then according to that data set controller demand data from model
5.model return data set(D2) to the controller
6.then controller send second data set(D2) to view.

第二种方法

1.send request to the controller
2.calling service layer methods from controller
3.service layer demand data from model
4.model send requested data set(d1) to the service layer
5.after some processing return generated data(d2) to controller from service layer
6.then controller send data set(d2) to view. 

在 CodeIgniter 中实现服务层的正确方法是什么？除了这两种方法，还有其他好的方法吗？

如果你能在代码中提供一个例子，那就太好了

Answer 1

Please note, this is not necessarily the correct way of doing it, but I'm going to explain how a framework like might typically do it and then you can learn about other methods and decide the best one for your use-case. Therefore, I do not expect this answer to be the correct one, but I hope it imparts at least a little knowledge on how things are done before someone who actually knows what they're talking about comes along and chimes in (also to those people - please feel free to edit / downvote this answer :D). Finally this also has nothing to do with CodeIgniter but frameworks in general. Your question should not only be framed as framework-agnostic, but language-agnostic also.

所以我将在这里提出一个观点，即所有现代框架，特别是 PHP，不做MVC .为什么这很重要？因为我们都需要说同一种语言，而 PHP 中不存在“mvc”。这是事实。接受这一点，然后我们可以继续将框架使用的概念混为一谈； CodeIgnitor 是“MVC” SCSS 化的一个特别好的例子；此后称为带引号的“mvc”。

好的一面是，例如像 Symfony 这样的框架，提供了一个初始的自以为是的架构，它至少包含跨应用程序的某种形式的一致性，它是这样的:

一个标准的 HTTP 请求进入并命中前端 Controller ，通常是 app.php或 app_dev.php取决于您是否处于开发或生产阶段；一个涉及需要在每次更改时运行的大量缓存，而另一个则不涉及 - 这对于开发来说是完美的。

路由器将当前 url 与 Controller 类和该类中的“操作”(方法)相匹配。

框架的依赖注入(inject)部分计算出从 Controller 到模型层再到后面的所有内容都需要哪些对象，并在需要时实例化或准备实例化它们。

Controller 使用任何所需的依赖项进行实例化，并执行相关方法。这通常是您开始开发并将代码“ Hook ”到框架的地方。

这是您决定架构的地方，但是，从开发人员角度和业务角度(为了降低 future 维护成本)而言，最重要的事情是一致性。

我个人更喜欢确保我的代码与框架分离。我将从请求中获取的标量传入应用层服务，该服务使用来自模型层(通过 DI 传入)的对象来使用域对象。这里的重点是域对象不直接传递到 Controller 中，它们通过应用层介质进行代理，因此理论上您可以替换围绕此的整个框架，并且仍然需要做的就是将这些标量传递到该层在它们到达模型层之前，它仍然可以工作(想想 CLI 调用，没有更多的 Controller )。

应用程序级服务使用任何必需的 Repositories , Services等等(并将这些标量传递给它们，还记得分离吗？)，它们执行业务逻辑，(通常这些是您的设计模式在日常工作中发挥作用的地方)，然后将该数据返回给应用程序-服务水平。

然后服务将数据返回给 Controller ，你猜怎么着？这就是框架容易搞砸的地方!因为在今天的框架中没有“ View ”的概念。只有一个模板，您将数据传递给模板，然后就是这样。所以在你的图中，绝对没有 View 的概念，因为事情不是这样完成的。老实说，我仍在使用模板，因为它们是最快的做事方式，但是直到现代框架把它们的东西放在一起并真正开始使用 View 之前，我们运气不好，必须在面对时保持坚定事实上，一些(如 Laravel)将自己称为“mvc”框架。

Note, Fabien Potencier explicitly states that Symfony was not an MVC framework - at least he knows what he's talking about there. Again, this is not purist, it's important we're all speaking the same, factually correct language in computing.

所以，因为你非常喜欢图表，下面是一些人如何用今天的框架来做...


这是针对具有 Review 概念的应用程序。和 Criteria每个Review .甚至不要让我开始使用 Symfony 表单，它们与所有事物如此耦合，它们并不是任何架构的重要组成部分。

你需要多少效果层？我们已经有了“MVC”，在 DDD 中我们有“应用程序”、“域”和“基础设施”分离的概念，所以先让这两者一起工作，然后是这个“服务层”？你真的需要另一层，还是上面的就够了？需要考虑的事情...



看，由于这种分离，您并没有被框架/http 请求困住来使应用程序运行。

看到上图中的“服务”了吗？它们与 Controller 分离，因此您可以从任何地方抛出标量，应用程序仍然可以工作。 我认为这会给你你需要的分离 .以正确的方式做事，学习如何做，然后学习如何控制自己并在涉及业务和需求时务实，这是很棒的，但是框架需要整理它们的东西 - 你当然不会使用 CodeIgniter 编写可爱的代码；)