By default, any object with related objects (e.g. in our Examples Site Database, an example of this is how the Project object has a related ManagerPerson object) will perform "late binding" on that related object.

So given our example, when you load a given Project object, the $objManagerPerson member variable is initially NULL. But when you ask for the ManagerPerson property, the object first checks to see of $objManagerPerson is null, and if it is, it will call the appropriate Load method to then query the database to pull that Person object into memory, and then bind it to this Project object. Note that any subsequent calls to the ManagerPerson property will simply return the already bound Person object (no additional query to the database is needed). This Person is essentially bound, as late as possible, to the Project, thus the term "late binding".

The advantages of "late binding" is that the data going between the database and the application is as minimal as possible. You only get the minimal amount data that you need, when you need it, and nothing else. And fortunately, because the Qcodo generated code does the binding for you behind the scenes, there is nothing that you would need to manually code to check, enforce or execute this binding functionality.

The disadvantage, however, is that for some functionalities where you are performing LoadAll or LoadArrayBy, and you need to use related objects within those arrays, you end up with "N+1 round tripping". This means that if you had 100 objects, you are essentially doing 101 round trips to the database: 1 queries to get the list of 100 objects, and 100 additional queries (one for each object to get its related object).

In this example, we LoadAll all the Project objects, and view each object's ManagerPerson. Using the built in Qcodo Database Profiler, you can see that five database calls are made: One call to get all the projects (four rows in all), and then four calls to Person::Load (one for each of those projects).