Home >Backend Development >PHP Tutorial >PHP method location
We encountered a problem when using PHP
For example, I now have three tables
User table: User
Product table: Goods
Voucher: Ticket
User address: Address
Therefore, there are three objects corresponding
User, Goods, Ticket, Address
I now have several functions: get the user's voucher, get the user's available vouchers, get the user's address list, get the goods purchased by the user
This is what I do now
<code class="php">class User extends Model{ public function oder() { return OrderRepository::getByUserId($this->id); } public function successOrder() { return OrderRepository::getSuccessByUserId($this->id); } public function cancelOrder() { return OrderRepository::getCancelByUserId($this->id); } public function address() { return AddressRepository::getByUserId($this->id); } ... }</code>
Why do you do this? I think it is more reasonable to put the operations closely related to the user into the user object! This alone feels quite redundant. How do you usually organize it? It seems that it may also cause the User class to be too large. !
How do you usually deal with it?
We encountered a problem when using PHP
For example, I now have three tables
User table: User
Product table: Goods
Voucher: Ticket
User address: Address
Therefore, there are three objects corresponding
User, Goods, Ticket, Address
I now have several functions: get the user's voucher, get the user's available vouchers, get the user's address list, get the goods purchased by the user
This is what I do now
<code class="php">class User extends Model{ public function oder() { return OrderRepository::getByUserId($this->id); } public function successOrder() { return OrderRepository::getSuccessByUserId($this->id); } public function cancelOrder() { return OrderRepository::getCancelByUserId($this->id); } public function address() { return AddressRepository::getByUserId($this->id); } ... }</code>
Why do you do this? I think it is more reasonable to put the operations closely related to the user into the user object! This alone feels quite redundant. How do you usually organize it? It seems that it may also cause the User class to be too large. !
How do you usually deal with it?
Model classification:
user model only stores user-related items
order model only stores order-related items
Pay attention to splitting and decoupling the business
It can also be split into Logic layer, model data layer and service layer
The methods for obtaining data from each table are written in their respective Model classes. If you want to obtain data from multiple data tables, instantiate the Model corresponding to the table in the controller, and call their respective methods to obtain the data. In the Controller Integrate data.