Bare Bones Sql versus OR (?)
I have to say I disagree with Ingo’s comments about preferring “bare bones Sql” over O/R mapping technology. IMO, the two topics are orthogonal.
Data Access is all about solving high level use cases. There are no rules out there that say one must give up the explicit, low level control just because an O/R mapping technology is utilized. In fact, I would suggest that a good O/R mapping technology needs to be easy to use AND extensible. That is it should solve all the common problems easily, but at the same time allow low level control as required. Generation of sql statements is just one possible service an O/R mapping technology can provide. Due to the wide range of transactional requirements and relational schemas currently existing, I believe that even a world class O/R mapping technology can only support 90% of the real world, Sql generation scenarios.
In regard to the scenario Ingo suggests. ObjectSpaces will provide the ability for the user to provide their own custom sql statement (including stored procedures) to both select data from the database and to persist changes. ObjectSpaces also gives the user full control over the Sql connections, thereby allowing explicit control of the transaction semantics. Sure, a majority of ObjectSpaces users will not need this sort of control, but it will be there for the ones who do. I really don’t see any reason why ObjectSpaces couldn’t solve the Ingo’s scenario.
Comments
- Anonymous
February 20, 2004
The comment has been removed - Anonymous
February 20, 2004
O/R is goofy outside of wizard UI design tools for script kiddies. EJB was going to save the world, too. - Anonymous
February 22, 2004
Hey Skeptical,
The problems with EJB are enormous (see the book Bitter EJB). In fact, O/RM is offered as a solution to some of the problems with EJB. Are you saying you would rather hand code all the SQL for hundreds of business objects in a large project? - Anonymous
May 04, 2004
I have done bean managed, container managed, and OR mapped with POJOs and from real project experience the latter is my choice when I must maintain and support the system put into production. Given you choose one of the two leading tools (hibernate and Toplink) life is easy and you don't need a graphics tool to maintain the mappings only a knowledge of xml and the configuration options for the chosen tool(though given you believe in agile dbas its a help to them.) In terms of performance, I was a skeptic in terms of all this before I actually starting using it and finding out for real what the overhead is for OR tools. I did some measurements and found that for navigational queries the overhead was like 50 ms) over a stored procedure approach. Even for normal queries, I have started to move to the query support provided as it decouples me from the underlying datastore.
For .NET, I hope that ObjectSpaces will provide many of the same features as I like to focus on solving the business problem and not the plumbing. However, I'm realistic in my expectations as on the Java side it took 4-5 years (using work done in Smalltalk) to get some really good persistence engines that performed as needed for mission critical apps. However, I'm very happy to see .NET consider and support the general concepts of transparent persistency and not force an implementation model into the domain model.
Looking forward to the future version of ObjectSpaces... - Anonymous
June 08, 2009
PingBack from http://jointpainreliefs.info/story.php?id=430