Feb 5
Yesterday, I asked Mark Mandel for some advice on tuning my object model for performance. Mark, being an ever-so-helpful (P)OSS author, gave me a few suggestions. Turns out that someone asked basically the same question on the transfer list today. Jaime Metcher made a couple of excellent points on choosing between queries and object composition. Paraphrasing, Jaime, when working with large data sets (the type of thing you might be tempted to use arrays of objects for), you will get better performance using a query. If you want to display a single instance of some object and the view is truly a composite, then your model should reflect that composition. Understanding this helps with choosing between onetomany or manytoone relationships for your object compositions.I have a pretty good use case going on right now for just this type of thing, an accounting system. Knowing that I will want to have an Invoice view that has InvoiceItems and Payments, I chose to make those relationships onetomany. To display an Invoice, I pull a single composite object and loop over the InvoiceItems and Payments as arrays. I do the same with Orders (which can recur) and OrderItems. All of my remaining relationships are manytoone, so that when I load an object high up the food chain, I don't load cascading arrays of child objects.
Here's a generic diagram of (some of) the objects in my model.
This was a big revelation for me in terms of modeling. I've always known at a low level that the view should drive the model, but this exercise really drove it home. Of the many learning points I've had over the past couple of months (ant here have been many), this one feels most significant.
This was a big revelation for me in terms of modeling. I've always known at a low level that the view should drive the model, but this exercise really drove it home. Of the many learning points I've had over the past couple of months (ant here have been many), this one feels most significant.
Feb 5, 2008 at 8:45 PM I know it's a little tangential, but let me plug IBO's here. With arrays and queries, you don't get the encapsulation of getter logic than non-trivial business objects might want. If you have an invoiceitem unit cost, invoiceitem quantity and invoiceitemtotalcost, for many use cases the third should really be calculated in the invoiceobject.getItemTotal() custom getter. A single IBO provides the performance of a query or array and the getter/setter encapsulation of a collection of objects.
I definitely agree about views driving the object model. I actually posited a dev approach where all you'd ever do is specify views and actions in DSLs and the object model would be inferred purely from a full set of views and actions. In practice it isn't a great approach, but it is true that an acceptable object model could be inferred by simply having a full set of interfaces (including imports, export, log files, and APIs as well as screens and controller actions) for a black box application.
Feb 5, 2008 at 11:41 PM Peter,
Shameless that you should mention IBOs and not Recordset in the same breath. ;)
In my quest to become a better modeler, I had forgotten how a simple, yet powerful, IBOs are. Gives me some food for though for some list pages that I know are going to need calculated values...