Late Binding: The Default Load Method
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
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
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
, 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
. 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
(one for each of those projects).
: 6 queries performed. Please