On Apr 16, 2007, at 5:35 PM, Ian Piper wrote: > I have been recently working through updating an old application and > making it better behaved in terms of object orientation. The > application has a variety of REALSQLDatabase tables that I need to > read in and display, and as I have been updating I have been creating > a set of classes that effectively model the data. The further I have > gone the more I think that actually I should be abstracting the whole > process of what is effectively ORM - I have a whole range of > (probably highly redundant) methods now for (for example) reading the > columns from a row of table tA and and instantiating object oA. I can > do (well I have been doing) this myself, and could probably sort out > an abstract process for doing it more tidily, but I wanted to know > whether there are some exemplars of good practice in taking a data > model and generating the appropriate classes (with properties, > accessor methods and so on), handling the inserts, updates, deletes > and so on.
I've worked through doing this once. I created a pretty decent ORM, but in doing it, I've realized some things I would have done differently. I would love to find a way to develop a really good ORM library, open-sourced, for REALbasic, but it would take a fair amount of work. If anyone is interested, I might be able to put together a couple of my clients with some other folks to share the cost of developing it. Anyhow. The key is to use Operator_Lookup. This lets you point an object at a RecordSet and load its field values as "properties". And because you have a single point of contact with all of them, you can track when they change, so you only need to write out the changes to the database. You also track all the records you've already turned into objects, so if someone asks for an object for a row you already have in memory, you can give them that one instead. The new weak references feature makes this practical now. That much is easy. What gets tricky is supporting inter-table relations and polymorphisms. You may not need the latter, but you almost certainly need the former, and they can come in at least three forms: many:one, many:many and recursive, and each needs special treatment. What I would do if I was doing this again is to create a core class for a DynamicObject that did the Operator_Lookup thing with its properties, and then let it accept plug-ins that intercept various operations to monitor or change them. You would then create plugin generators for the relations and so on. You could do something almost as good as the Ruby on Rails ORM (say). The only really significant obstacle is the lack of first-class classes The first time I did this, I created a subclass of the DynamicObject for each table. I don't think I would do that if I could start over, because it involved writing a lot of almost- identical shared methods. If we had first-class classes, that would have been the way to go, but I think as things stand, you should just have a single class that handles all tables. On startup, you'd be able to execute calls on it that declared all your relations and so on. You could then write wrapper classes or something so that you could still have a class for each table. As I say, I have a couple of clients who might be interested in contributing to a really full-on ORM. If anyone else can throw in, I'd be happy to lead an effort to develop something we can all use. 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: <http://support.realsoftware.com/listarchives/lists.html>
