I have felt ambivalent about relational databases for some time. On the one hand, they are very good at some things, particularly dealing with large volumes of data very quickly, indexing and the like; on the other, they play by their own rules, and tend to force developers into thinking about their data in terms of tables, keys, and the rest of it.
A lot of projects don’t need to think about their data in this way, and a lot of unnecessary code ends up being written to cope with it. To some extent, systems like Hibernate and ActiveRecord ameliorate this issue; but in my experience, you still end up building your objects in a certain way to cope with how they work - a way that has nothing to do with the world you are mapping with your object model.
Enter Google’s DataStore API, the object persistance layer API available to developers of apps on Google AppEngine. I have only just started trying to tinker with it (my abilities in Python are pretty limited) but it seems like it approaches the idea of persistant data in a much more object-friendly way. Look at this sample code (from their website) …
user_pets = db.GqlQuery("SELECT * FROM Pet WHERE pet.owner = :1",
users.get_current_user())
Just like SQL? Not quite … users.get_current_user() returns an object, not a numeric ID. Quite a difference!
So, our backend data storage can work with real objects. How about Flash? I was hoping for some kind of BlazeDS-alike for Python, but at least there is PyAMF, a Python implementation of AMF3 (and AMF0 for legacy apps). The great thing about this is that we can define objects that retain their type (inasmuch as differences in language permit), regardless of which layer we are working in: persistance, business logic, presentation. This means our OOA/D can correlate more closely to the actual finished system, which is a good thing.
When I get a few spare minutes, I’m going to have a go at building something with these technologies and put it up on the AppEngine … watch this space.
Recent Comments