I'm writing my own PHP MVC framework and I was wondering which is the most appropriate place to code persistent data objects like User for instance. Without persistent storage like $_SESSION, APC, memcached,... someone could retrieve user data from the database every http request, which is a bad idea in terms of performance. (M)odel seems like a good choice. Is something like this a good start:
class UserModel extends Model
{
public function getEmail()
{
$user = Session::get('User');
if(isset($user))
{
return $user->Email;
}
return null;
}
}
Probably not, as it is not returning db data which is most Models do. Should I create an independent class? Is there any pattern for this? I wouldn't like to make it global, who is the owner/manager for such objects?
Your models should only model the business logic. They should not have anything to do with user interaction. That's the job of the controller (and view). Sessions are squarely in the realm of user interaction. So don't use them in models. Always assume you will be using models from the command line or some other context where sessions do not exist. That should inform a lot of your application design.
You can implement caching at various stages to reduce load on the primary data store. You should have a model layer or service layer, which expresses the core logic of your app. This layer has a defined API which you use to do things in your app. Maybe behind the scenes that layer caches some data internally using memcache etc. to reduce load on the database.
Then you should have a view layer, which gets data from the model layer and visualizes it. That view layer may cache data it received from the model layer somewhere.
The biggest takeaway: separate your concerns properly. See N-Tier Architecture - An Introduction, which may give you some more ideas.