This post originated from an RSS feed registered with Agile Buzz
by James Robertson.
Original Post: Tunnel Vision
Feed Title: Cincom Smalltalk Blog - Smalltalk with Rants
Feed URL: http://www.cincomsmalltalk.com/rssBlog/rssBlogView.xml
Feed Description: James Robertson comments on Cincom Smalltalk, the Smalltalk development community, and IT trends and issues in general.
Ted Neward has a post up talking about the pitfalls of O/R mapping - now right off, I have seen plenty of Smalltalk projects go down the road to hell trying to build their own O/R frameworks - so it's possible to fall off the cliff. Smalltalk is certainly no silver bullet here. On the other hand, I've also seen many projects succeed quite well here. I think Ted overstates the problem:
Both major software vendors and project teams (building their own O-R layer) fall into the same trap. With object-relational technologies, products begin by flirting with simple mappings: single class to single table, building simple Proxies that do some Lazy Loading, and so on. "Advisers" are sent in to the various project teams that use the initial O-R layer, but before long, those "advisers" are engaging in front-line coding, wrestling with ways to bring object inheritance to the relational database. By the time of the big demo, despite there being numerous hints that people within the project team are concerned, project management openly welcomes the technology, praising productivity gains and citing all sorts of statistics about how wonderful things are going, including "lines of code" saved, how we were writing far more useful code than bugs. Behind the scenes, however, project management is furious at the problems and workarounds that have arisen, and frantically try every avenue they can find to find a way out: consultants, more developers, massive code reviews, propping up the existing infrastructure by throwing more resources at it, even supporting then toppling different vendors' products as a means of solving the problem. Nothing offers the solution the team needs, though: success, a future migration path, or at the very least, a way out preserving the existing investment. Numerous "surprises" (such as the N+1 query problem thanks to lazy-loading proxies or massive bandwidth consumption thanks to eager-loading policies) make the situation more critical. Finally, under new management (who promise to fix the situation and then begin by immediately looking to use the technology in other projects), the team seizes on a pretext, ship the code and hand it off to system administrators to deploy, and bring the developers home to a different project. Not a year later, the project is cancelled and pulled from the servers, the project's defeat complete in all but name.
There have been two really nice O/R frameworks done in Smalltalk (that I know of - there may well be more) - TopLink and GLORP. GLORP is an active project, and getting quite nice early reviews from people taking it up. Sure, projects can fall over dead in the attempt to build a "perfect" O/R layer - but projects can far, far more easily fail by scatter shotting SQL throughout the code base. What is Ted actually advocating here? Does he have a proposed solution, or is it just carping? Inquiring minds want to know :)
Previous Topic
