About PHP actual combat, the project structure, I want to ask you!

  question

1. Briefly introduce what I understand now. We are now doing projects, such as shopping malls. Although we are using MVC pattern for development, I feel confused that it is not MVC. Moreover, our colleagues in the company are all developed in this way, which makes me feel that we are closed to the outside world. So I would like to ask you what PHP people think.

Next, I will use code to describe it.

//user.php [controller]-user controller
 
 class user {
 
 //Get user information [interface, or controller entry]
 public function getUserInfo(){
 $mUser = new UserModel();
 $tUser = $mUser->getInfo($this-userId);
 
 echo json_encode($tUser);  //output information
 bracket
 
 
 
 //For a more complicated controller, place an order, for example.
 public function order(){
 $product = I('product_id');  //product id
 $address = I('address_id');  //harvest address id
 $coupon = I('cuopon');  //red envelope id
 $bouns = I('bouns');  //gold volume id
 
 
 # Check if produt Exists
 //code   .....
 
 # Check whether red envelopes are reasonable
 //code   .....
 
 # Check whether the cash coupon is reasonable
 //code   .....
 
 # Check whether the address is reasonable
 //code   .....
 
 # Get Freight
 //code   .....
 
 # Operation Order Data
 //code   .....
 
 # Save Order to Database
 //code   .....
 
 
 Echo 'success';
 
 //Finally, I would like to express that if there is more business logic, our operation is,
 //will put this series of business logic in the controller.  Is there a problem with this?  ?  ?  I always feel that it is very complicated to do so.
 bracket
 
 bracket

Model:

//user model [tp for example]
 class UserModel{
 
 public function getInfo($userId){
 
 //Our understanding is to encapsulate the operation with the database model.
 $tA = M('user')->where(array('user_id'=>$userId))->find();
 
 //below, you can also perform some data operations.
 
 return $tA;
 bracket
 
 //A more complicated model
 public function getOrderInfo($id = '', $code = '',$userId = ''){
 
 //The general point of this method is that when we re-develop, we will always be like the first method.
 //The writing is very concise and looks like a single responsibility.
 //After writing, you find that the method can be reused by adding a parameter.
 //Then in the end, you will faint.  What exactly is this method used for?
 //Q: The design principle of this method should be a single responsibility. If it is necessary to reuse this method, is it reasonable?
 //How should we design it better?
 
 
 
 bracket
 bracket
//Finally, identify the designed architecture in some ways
 
 C - controller
 M - model
 
 
 For example, an operation
 Request interface -> C-> call method 1 of m
 -> call method 2 of m
 -> call method 3 of m
 -> call method 4 of m
 -> call method 5 of m
 -> call method 6 of m
 -> output results
 //This is the structure of colleagues in the company. They always feel that my model only needs to be packaged.  Then the controller can always process the business logic in this way
 
 //My question is, there seems to be nothing wrong with this, but it is quite difficult to read, because there is a little dependence between each method (referring to M's methods 1...6)
 //If you add or subtract an M method, then you have to read the entire business logic code, which is very complicated.
//Finally,
 //My ideal business logic is
 
 C -> M method 1 -> M1 method 1->M2 method 1
 -> M2 method 1 ->M1 method 1->M2 method 3
 
 
 //I wonder if it can be done. A business logic seems that each piece is a single responsibility, with an entrance and an exit.

I don’t know if I made myself clear, ha, ha, ha.
Let’s sum up some. I want to learn about the architecture design of everyone’s development project and the architecture of MVC pattern. Please share it with me. okay?

There is no uniform standard, I can share our practice, we are not 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 |  ...

Like this
App is the project directory:

  • Comps is the module catalog, dividing the project into corresponding modules;
  • Transformer Method to print format Data (External);
  • Module file is the module entry (external);
  • Repository is the warehouse (internal) for database operation Model;
  • Service is to deal with complex logic (internally);
  • Trait is the export of externally exposed Module and Transformer files;
  • Config is the configuration directory
  • Helpers is the directory for supporting files
  • Models is the database Model directory.
  • Doc is the document directory.
  • Controllers are routing directories;

Controllers can only call the Module and Transformer files in the module directory through trait. calls between modules can directly call each other’s modules, but! Server and Repository cannot be called across modules