what is $em ?! I think you are assuming I know what this is, while in face I dont have the slighest clue.
The $em variable would hold an instance of something known as an Entity Manager. That is basically a class that knows about your different entities (Users, Messages, Blogs, Photos, whatever) and handles the creation of those entities. Something like
would be asking the entity manager that you want it to find the User entity with ID #1 so what it would do is generate the appropriate query to pull the information from the database, create a new instance of the User class, and then set all the properties of that class with the values from the database. How it knows what to do generally comes down to two possibilities:
A) Everything follows a strict naming standard. Your class names match up with your table names. Your property names match up with your column names. And so on for any other cases
B) or everything is configured via some configuration file which defines which entities your application has, what class is used to represent them, which properties match up with with columns, etc.
The second approach is more flexable generally but also more work in the initial setup. Often there is a script you can use that will apply the principals of method a to automatically generate a configuration for method b which can then be tweaked if necessary.
Second, you already have the $from variable, so why would you add it to a class and then fetch it from the same class. What am I missing here?!
The point is about having consistant interfaces and being able to use them easily. In the example above, there is some class that is used for sending email messages between users. It accepts two User objects and the message as it's parameters and then acquires the user's email (and potentially other details, ie user ID, names, etc) from those user objects by calling the appropriate properties (ie, $from->getEmail, $from->getName, etc). By having your code always deal with user objects you then always have a nice consistant way to access a users data.
Also, "without needing a database". Do $from and $to just magically appear? Unless you fetch from a form (get, post) or from a session or something, that information is already likely fetched from a database.
One prime example of not needing a database would be if you do Unit Testing. In such an environment you would create "fake" data and use that to do the test. So in the example you'd create two User objects with fake details and pass that to your messaging object in order to test that it is working properly. Rather than go through a huge hassle of setting up a DB and anything else that might be neccessary for that to work you just create two simple objects, set their details, and go.
Now, all of that said/explained:
How do you guys do this?
Our application is similar to what you have said where we have methods that return an array of all the various information for a given entity. For the most part I've gone the route of using a single method, GetDetails, with parameters to control which information to load. For example we have a Student class that returns details about a student. Whether it loads additional details about their enrollments though is a parameter. The method is defined as
public static function GetDetails($studentId, $loadEnrollments=false);
When all we need is things like their name, email, etc then we skip loading the enrollments. If we need the enrollment data then we just set the second parameter to true in order to have it pull that information as well. As far as which is best, separate methods vs parameters, it doesn't really matter. Either will work fine, neither is really fantastic. Something more advance like describe in previous posts would likely be best just from a maintainability/testability point of view, which is the most important point of view.