Question

By business model, or business objects, I mean plain old objects like a “User” with all their properties name, adress, …; in addition to all the user properties let’s say each user would have an “AppointmentBook” object, each book has a set of “TimeSlot” objects, etc.
The business model has objects with references between them, at least that’s how I code a business model in Java.
Here comes the question:

To intialize my business objects, in Java, I would

1. fetch all of the data from DB only once during application
   initialization,
2. map data from my DB to my business objects
3. store in memory (maps) and they would be shared across all the requests.

PHP‘s Share-Nothing-Architecture is confusing me for proper OO programming:
If I use the same logic, I would have to fetch all the objects from DB, for every request (I know I could still cache, but you don’t cache all of your DB, it’s not a question about caching but rather about the way of programming in PHP and its architecture).

So let’s say that for one HTTP request, I just need the User properties and I don’t need to access his appointment book. It would be a pitty to fetch all the data from the DB for all the objects the User makes reference to, as I just need his properties. This means that I will initialize PHP objects from my model with a lot of NULL values (NULL because of the objects contained in User that I won’t load) which can later on lead to errors.

I was wondering how professional PHP developers usually use their business objects?
(I’m coming from Java)

---

UPDATE: It was kind of stupid to say that I would load the whole database into memory during application init in Java. What I rather meant is that, if I need to fetch a specific user, I could just load all of its data and that would be accessible through all the requests.

Answer 1

In PHP you do not keep all the data of your domain business model in the memory. Instead you only request from DB ( though cache, if needed ), the data you want.

Model layer in php should be built from multiple domain object and data mappers ( i assume, that part is not so different from Java ). If you need User details, then you fetch only that information from database/cache. You most likely will have a separate mapper just for dealing with user(s).

You display the information about that user, and forget about the query. Next request (when and if it comes) will require different information. Maybe you will want ContactList for that User … then you really do not need user itself, only his user_id. Again, you let you mapper to fetch data into the domain object responsible for handling contact list, and if contact list contains User instances, then just create them, but leave in “unfetched” state (object knows only own user_id). Fetch them only if you really need to, and only the parts which you will use ins that “view”.

---

P.S. you might have notices, I told that model later should be segmented, but quite often php developers just create single class of each DB table (which implements ActiveRecord) and call it “model”. This is a result caused by Ruby on Rails influence on php framework developers, which, IMHO, is one of the worst things that has happened to PHP in past 5 years.