I’m working on a flash gaming website. I have two models: Game and User and an intermediate table in which I keep the user’s actions as for example: “User 1 likes Game 3”.
- Where is the best place for my like function?
- Is it a good practice to grab current user id in Game model? or should I pass it as parameter?
For performance reasons, I increment likes field in game table too.
I’ve omitted to check if user already likes the game just to keep it simple.
Here are my options:
First version:
$user->like(12345);
class User
{
public function like($game_id)
{
$like = new User_Game();
$like->user_id = $this->id;
$like->game_id = $game_id;
$like->save();
$obj = new Game($game_id);
$obj->likes++;
$obj->save();
}
}
Second version:
$game->like(); // by current user
class Game
{
public function like()
{
$like = new User_Game();
$like->user_id = $_SESSION[‘user_id’];
$like->game_id = $this->id;
$like->save();
$this->likes++;
$this->save();
}
}
To be perfectly honest, I’m not sure if this is the best place for a question such as this. Perhaps codereview is a better fit. All things aside, IMO, neither of the two takes you suggest are “the best approach”. But as always, that might be a personal thing.
In my view, the best way to go about OOP, is to push all your data in objects ASAP, and implement a service layer that takes care of operations that require multiple queries, or several objects.
If I may assume you’re using an MVC-ish pattern, your controller receives the data. There, you instantiate a
Gameobject, and set the id to123456. You can pass that instance to a service method calledfillGameModel(Game $gameInstance). This method connects to the DB, and sets all other properties of theGameobject and returns it. Same goes for theUserobject. Both of these objects can then be passed to another service method:likeGame(Game $game, User $user). That method can take care of the rest.Personally, I’d go even one step further and use mappers for my DB access, but I’m not going into that now. Here’s an example using a service, and a more OO approach:
Again, the loops through the resultset could be replaced with a method in an abstract model class that takes an array as argument, and transforms the fieldnames to their corresponding setters. Plenty of room for abstraction, I’d say 😉