关于PHP实战中，项目架构，我想请教一下各位！

Question

1，简单介绍一下，我现在理解的。我们现在做项目，比如商场。我们虽然是采用的MVC模式进行开发，但感觉其中让我有些迷茫的是，感觉像不是MVC。而且，我们公司的同事，都是这样开发的，让我觉得，我们好闭关锁国。所以想请教一下，各位PHP们的看法。

：接下来，我就用代码来描述一下。

//user.php[controller] -- 用户控制器

class user {

    //获取用户信息[接口，或者是控制器入口]
    public function getUserInfo(){
        $mUser = new UserModel();
        $tUser = $mUser->getInfo($this-userId);
        
        echo json_encode($tUser);//输出信息
    }
    
    
    
    //复杂一点的控制器 举例用下单。
    public function order(){
        $product = I('product_id');//产品id
        $address = I('address_id');//收获地址id
        $coupon = I('cuopon');//红包id
        $bouns = I('bouns');//代金卷id
    
        
        #检查produt是否存在
        //code .....
        
        #检查红包是否合理
         //code .....
         
        #检查代金卷是否合理
         //code .....
         
        #检查地址是否合理
         //code .....
         
        #获取运费
         //code .....
         
        #操作订单数据
         //code .....
         
        #保存订单到数据库
         //code .....
         
        
        echo '成功';
        
        //最后，我想表达的是，如果业务逻辑较多，我们的操作是，
        //会把这一系列的业务逻辑都放在控制器里面。这种有问题没？？？，我总觉得，这样做很复杂。
    }

}

模型：

//user 模型 [tp为例]
class UserModel{

    public function getInfo($userId){
    
        //我们的理解是，将与数据库模型操作的，封装起来。
        $tA = M('user')->where(array('user_id'=>$userId))->find();
        
        //下面，还可以进行一些数据的操作
        
        return $tA;
    }
    
    //复杂一点的模型
    public function getOrderInfo($id = '', $code = '',$userId = ''){
    
        //这方法的总点是，我们再开发中，总是会先像第一个方法一样，
        //写的时候很简洁，看起来就是单一职责，
        //写到后面，你发现那个方法，其实可以加个参数，就可以重用了。
        //然后到最后，你就晕了。这个方法，到底用来干嘛的，
        //问：这种一个方法的设计原则，应该是单一职责吧，如果需要重用这种方式是否合理，
        //应该怎么来设计比较好？
        
        
        
    }
}

//最后用一些方式来标识设计的架构

C - controller
M - model


例如一个操作
请求接口 ->  C   -> 调用M的方法1
                -> 调用M的方法2
                -> 调用M的方法3
                -> 调用M的方法4
                -> 调用M的方法5
                -> 调用M的方法6
                ->输出结果
//这是公司同事的架构，他们总觉得，我的模型，只要封装好方法就行了。然后控制器，可以一直这样处理业务逻辑

//我的问题是，这种看起来是没有错，但阅读起来，难度相当大，因为每个方法之间，依赖有点多(指M的方法1...6)
//如果你增加，或者减少一个M方法，那你就要阅读整个业务逻辑代码，好复杂。

//最后，
//我的理想业务逻辑是

C ->  M方法1 -> M1方法1->M2方法1
  ->  M2方法1 ->M1方法1->M2方法3


//我想的是，能不能做到，一个业务逻辑，看起来每一块都是单一职责，都有一个入口，和一个出口，

不知道我表达清楚没，哈哈哈。
总结一些吧。我想学习一下大家开发项目的架构设计，关于MVC模式的架构。请大家和我一起分享一下。好吗？

Answer 1

没有统一的标准吧，我可以分享一下我们的做法，我们不是mvc。

app |
    |- Comps |
             |--- Article |
                          |--- ArticleTransformer.php
                          |--- ArticleModule.php
                          |--- ArticleRepository.php
                          |--- ArticleService.php
                          |--- ArticleTrait.php
    |- doc |
           |--- sql |
                    |--- sql
    |- Config |
              |--- database.php
    |- Helpers |
               |--- Support.php
    |- Models |
              |--- Article.php
https |
      |- Controllers |
                     |--- Article |
                                  |--- ArticleController.php
                     |--- register.php
                     |--- routes.php
vendor |...

比如这个
app为项目目录：

• Comps为模块目录，将项目分成相应的模块；
• Transformer方法来格式化输出数据（对外）；
• Module文件为模块入口（对外）；
• Repository为数据库操作Model的仓库（对内）；
• Service为处理复杂逻辑（对内）；
• Trait为对外暴露Module和Transformer文件出口；
• Config为配置目录
• Helpers为支持文件目录
• Models为数据库Model目录
• doc为文档目录
• Controllers为路由目录；

controllers只能通过trait来调用module目录里面的Module和Transformer文件，模块之间的调用可以直接调用对方的module,但是！Server和Repository不能跨模块调用

Answer 2

json 响应可以封装成一个基类，然后控制器继承，返回时统一调用基类的方法。

把控制器中可以分离的都解耦到Service层，然后注入到控制器中，你这个应该是 TP， TP5 应该有依赖注入了。
表单验证可以考虑使用更面向对象的方法，比如这样的：

最后那两个画的没看得清楚。
我通常是这样写的