在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中实现服务层的正确方法是什么？除了这两种方法，还有其他好方法吗？

如果你能在Code中提供一个例子，它会很棒

Answer 1

请注意，这不一定是正确的方法，但我将解释一个类似的框架通常如何做，然后你可以了解其他方法，并为你的用例决定最好的方法。因此，我不认为这个答案是正确的答案，但我希望它至少能够提供一些关于事情如何完成的知识，然后才能真正知道他们所谈论的内容并且会进入（也是对那些人） - 请随时编辑/关注此答案：D）。最后，这也与CodeIgniter无关，而与一般的框架无关。您的问题不仅应该与框架无关，而且与语言无关。

所以我将在这里提供一个意见，这是因为所有现代框架，特别是在PHP中，都没有做MVC。为什么这很重要？因为我们都需要说同一种语言，PHP中不存在'mvc'。这是事实。接受，然后我们可以继续推进框架使用的概念的混合;和CodeIgnitor是'MVC'混蛋的一个特别好的例子;此后称为带有引号的“mvc”。

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

1. 标准HTTP请求进入并命中前端控制器，通常是app.php或app_dev.php，具体取决于您是否处于开发或生产阶段;一个涉及需要在每个更改上运行的大量缓存而另一个不需要 - 这对于开发来说是完美的。
2. 路由器将当前url与控制器类和该类中的“action”（方法）进行匹配。
3. 框架的依赖注入部分指出从控制器到模型层和返回所需的所有对象，并在需要时实例化或准备实例化它们。
4. 控制器使用任何所需的依赖项进行实例化，并执行相关方法。这通常是您开始开发并将代码“挂钩”到框架中的地方。
5. 这是您决定架构的地方，但是，从开发人员的角度和业务角度来看，最重要的是（为了降低未来维护成本）是一致性。
6. 我个人更喜欢确保我的代码与框架分离。我将从请求中获取的标量传递到应用程序层服务，该服务使用模型层中的对象（通过DI传入）来使用域对象。这里的要点是域对象不是直接传递给控制器​​，它们是通过应用层介质代理的，所以理论上你可以替换围绕它的整个框架，你需要做的就是将这些标量传递到这一层在它们到达模型层之前它们仍然可以工作（想想CLI调用，不再需要控制器）。
7. 应用程序级服务使用任何所需的Repositories，Services等（并将这些标量传递给它们，记住分离？），它们执行业务逻辑（通常这些是您的设计模式在日常工作中发挥作用的地方） ），然后将该数据返回到应用程序级服务。
8. 然后服务将数据返回给控制器并猜测是什么？这是框架往往搞砸的地方！因为在今天的框架中没有“视图”的概念。只有一个模板，您将该数据传递给模板，然后将其传递给模板。因此，在您的图表中，绝对没有视图的概念，因为事情并非如此。说实话，我仍然使用模板，因为它们是最快的做事方式，但是在现代框架将它们放在一起并实际开始使用视图之前，我们运气不好并且在面对时必须保持坚定事实上有些人（比如Laravel）将自己称为“mvc”框架。

请注意，Fabien Potencier明确指出Symfony不是MVC框架 - 至少他知道他在那里谈论什么。同样，这不是纯粹的，重要的是我们在计算中都说同样的，事实上正确的语言。

所以，因为你非常喜欢图表，所以有些人可能会在今天的框架中做到这一点......

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

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

请注意，由于这种分离，您不会遇到框架/ http请求以使应用程序运行。

请参阅上图中的“服务”？它们与控制器分离，因此您可以从任何地方抛出标量，应用程序仍然可以工作。我认为这将为您提供所需的分离。以正确的方式做事，学习如何做到这一点，然后学习如何控制自己并在业务及其需求方面务实，这是很好的，但框架需要对他们的东西进行排序 - 你当然不会用CodeIgniter编写可爱的代码;）

Answer 2

依赖注入和适配器模式将是一个很好的起点。 CodeIgniter支持既不开箱即用，所以你需要编写一个包装器或者一个钩子。

您的视图只能支持xml | html，因为json需要预先渲染到.json文件然后作为输出返回，但这需要通过代码完成，在这种情况下更容易返回对象并更改为前端。 PHP是一种嵌入式语言（xml | html）

服务模型在注入（依赖注入）到控制器/模型中时效果最佳，并被列为该控制器/模型的属性。

然后将该服务绑定到接口

例如facebook / twitter他们都有一个请求和响应函数，但都遵循类似的模式，但有不同的端点。

interface SocialMediaAdapter{
  public request(url);
  public response();
}

---

public class FaceBookProvider implements SocialMediaAdapter
{
     public request(url){

     }
     public response(){

     }

}

public class TwitterProvider implements SocialMediaAdapter
    {
         public request(url){

         }
         public response(){

         }
    }

---

public class SocialMediaServiceProvider{

    protected $provider = null;

    public function constructor(SocialMediaAdapter $provider){
       $this->provider = $provider;
    }

    public function fetch($url){
       return $this->provider->request($url);
    }
}

这里需要依赖注入

new MyController( new SocialMediaServiceProvider ( new FacebookService ) )

Answer 3

恕我直言，这里没有对错：

选项＃1 - 如果要在多个控制器/操作中重复使用服务层，并根据请求从不同模型中提供数据，则可以选择第一个。

选项2＃ - 但是，如果您的数据模型更复杂，则第一个选项可能会出现问题。如果根据第一个呼叫的数据需要对模型进行第二次呼叫怎么办？使用此业务逻辑的控制器违背了服务层的整个目的。在这种情况下，最好选择第二个。

我认为第二个是更常见的一个。

Answer 4

你应该使用第一个。因为在MVC Web应用程序中，控制器用于将业务逻辑与视图分离，所以它类似于网关。您需要使用控制器开始处理您的信息，您应该从控制器调用模型或服务层或您需要的任何内容，最后您应该将数据返回到此处的任何其他来源。您的视图或服务层不应直接访问模型。