0

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?

user1517081
  • 965
  • 2
  • 11
  • 30
  • Please, don't write one, there is just so much php frameworks already out there... You will waste a lot of time & will learn a lot less than if you would have first learned how existing framework try to solve common issues & what patterns are implied. Check Lithium/Symfony2 if you haven't. – Olivier Sep 03 '12 at 16:04
  • @Olivier I disagree. The world doesn't need *yet another open source framework*, true. But there's no reason against rolling your own application structure using no framework, which is tailored specifically to your needs. – deceze Sep 03 '12 at 16:11
  • @deceze I guess you are right about building something private, but the downsides are just so huge & time-consuming (security, orm layer) that it would not come to my mind, and given the rank of the op, I thought a fair warning was needed. – Olivier Sep 03 '12 at 16:18
  • @Olivier Well, having used a couple of frameworks, it can turn out to be a lot more time consuming to build on one of them instead of doing something tailor-made. The problem is that virtually no framework out there offers a *real*, proper, MVC setup. Building one yourself can be a lot less hassle than trying to shoehorn one into an existing structure. That's going rather deep for a single comment though... :) I'd agree though that a newbie may be better off working within *some* predefined structure at first, even if it's not the best. – deceze Sep 03 '12 at 16:23
  • 1
    @Olivier I'm aware there are hundreds of php frameworks out there, some of them are crapy, others are too complicated, difficult to understand, they may solve only part of your needs... This is why I'm writing my own framework, to learn and evolve together with my work. – user1517081 Sep 03 '12 at 16:33

1 Answers1

2

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.

deceze
  • 510,633
  • 85
  • 743
  • 889