We encountered a problem when using PHP. for example, I now have three table User tables: User commodity table: Goods coupon: Ticket User Address: Address, which corresponds to three object users, goods, Ticket, Address I have several features: get a user's coupon and get a user... we encountered a problem when using PHP.
For example, I have three tables.
User table: User
Item table: Goods
Coupon: Ticket
User Address: Address
This corresponds to three objects.
User, Goods, Ticket, Address
I have several features: getting users' coupons, getting users' available coupons, getting the user's address list, and getting the user's purchased items
This is what I do now.
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); } ...}
I think it is reasonable to put operations closely related to users into user objects! I think there is a lot of redundancy here. how do we sort out this! The User class may be too large!
What do you usually do?
Reply content:
We encountered a problem when using PHP.
For example, I have three tables.
User table: User
Item table: Goods
Coupon: Ticket
User Address: Address
This corresponds to three objects.
User, Goods, Ticket, Address
I have several features: getting users' coupons, getting users' available coupons, getting the user's address list, and getting the user's purchased items
This is what I do now.
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); } ...}
I think it is reasonable to put operations closely related to users into user objects! I think there is a lot of redundancy here. how do we sort out this! The User class may be too large!
What do you usually do?
Model category:
Only user-related
Order model only places order-related
Pay attention to business splitting and decoupling
It can also be split into Logic layer, model data layer, and service layer.
The methods for getting data from tables are written in their Model classes. to retrieve data from multiple data tables, instantiate the corresponding Model of the table in the controller, and respectively call their respective methods to obtain data and integrate the data in the Controller.