On Dec 7, 2006, at 6:51 PM, Tom Benson wrote:
I've studied database design, and am reasonably proficient at it,
however when it comes to building an Objective Framework for
interfacing with the database it seems you can go one of two ways,
and I'd like to know which one is preferable and why if anyone
would care to enlighten me as to the pros and cons, mainly in terms
of design efficiency.
Route 1)
Override each object constructors so that each object initialises
itself.
e.g. myCustomer = new customer(n)
In this case the customer object would query the database and
populate it's own properties
Route 2)
Have a factory module with methods for populating and returning
instances of these ojects
e.g. myCustomer = MyFactory.GetCustomer(n)
In this case the factory would do ALL of the database comms.
I can see the advantages of using a Factory object, but a lot of my
objects contain instances of other minor objects (e.g. an Address
is it's own object in this setup, and each Customer Object has an
Address Property), and the first option makes this easy by allowing
object creation to cascade automatically up the tree simply by
creating the root object.
I would say go Route 2, but this will depend on the particulars of
your application.
I tackled this recently, so I will pass on some related information.
If you want to actually make use of the database as it's intended --
for example, be able to find information in the database using
complex queries -- then you need to construct objects representing
that information from the results. Fine.
But you have the following problem: some of those objects may already
exist in memory. You want to use a factory method to solve this
because you can have the factory return the existing object if there
is one, and make a new one if there isn't. Fine.
But then you need your factory to keep track of *all* instances. This
points up one of the most serious deficiencies in REALbasic's
features: no weak references. Your factory will need to keep probably
a dictionary relating your primary keys to your object instances. But
now, if you lose every other reference to an object, you still have
your dictionary referring to it, so you'll never drop any objects.
In many applications, this is fine. If your database isn't huge, just
load up objects in memory and keep them. But if your application is
large, this is really serious problem. You basically will have to do
your own memory management.
I discussed here the idea of open sourcing my work, but I'm not sure
I'm keen to do that until we get weak references and some other
features (first-class classes, for example) that would make this
framework easier to work with (also, my experience writing the
framework has taught me how to do it really well, so I'd like to do a
major rewrite). If you're interested, I can talk to my current client
about maybe collaborating on that rewrite, and sharing the results,
or something. Contact me off-list.
I don't want to put you off. What I've created makes working with the
data really nice. All the UI part of my application neither knows nor
cares where the data lives. I'll probably develop a networked multi-
user version of my project next, and it won't be horrible to do that,
now I have this nice layer to support it. But it's still a bit of a
pain to work with, because some things just can't be properly
automated in REALbasic as it stands.
Regards,
Guyren G Howe
Relevant Logic LLC
guyren-at-relevantlogic.com ~ http://relevantlogic.com
REALbasic, PHP, Ruby/Rails, Python programming
PostgreSQL, MySQL database design and consulting
Technical writing and training
_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>
Search the archives of this list here:
<http://support.realsoftware.com/listarchives/lists.html>
