I gave a quick look to Class::DBI module, it seems to be very interesting ... I will start from there. Thanks for your feedback ... Perl is really great :-)
Jos�. -----Original Message----- From: Stephen Clouse [mailto:[EMAIL PROTECTED]] Sent: Wednesday, July 31, 2002 10:14 AM To: NYIMI Jose (BMB) Cc: [EMAIL PROTECTED] Subject: Re: Hard-coding SQL in DBI violates OO encapuslation ? -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Wed, Jul 31, 2002 at 09:25:15AM +0200, NYIMI Jose (BMB) wrote: > Dear, > > A friend recommended me this white paper: > > http://www.ambysoft.com/persistenceLayer.html > > The Author suggests to implement what he called "Robust Persistence > Layer" between "Business Classes" and "Storage mecanism" (ex > Relational Database"). > > Here an extrait from the white paper: > > "This approach to persistence effectively allows your database > administrators > (DBAs) to do what they do best, administer databases, without forcing them to > worry about what their changes will do to existing applications. As long as > they keep the data dictionary up-to-date they can make whatever changes they > need to make to the persistence mechanism schema. Similarly, application > programmers can refactor their objects without having to worry about updating > the persistence mechanism schema because they can map the new versions of > their classes to the existing schema. Naturally when new classes or attributes > are added or removed to/from an application there will be a need for similar > changes within the persistence mechanism schema." > > > Is there in Perl's world a way to avoid hard coding SQL in DBI. I > would like to have your opinion about this white paper. It's entirely correct in an OO context; however, you're confusing what the paper describes with DBI :) DBI is simply the low-level database driver that handles the interface to the database server. To fit it into the parlance of the aforementioned paper, DBI is the PersistenceMechanism object. Obviously you have to write SQL at some point, because there's no other way to talk to the database, and you need something like DBI to do the talking.. The point the paper gets at is to expose a data-centric object model to the application, and let the object worry about building and executing the proper SQL. Class::DBI is a good example of a Perl module that implements (most of) the rest of that diagram, and probably a good place to start looking. - -- Stephen Clouse <[EMAIL PROTECTED]> Senior Programmer, IQ Coordinator Project Lead The IQ Group, Inc. <http://www.theiqgroup.com/> -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux) iD8DBQE9R5w9A4aoazQ9p2cRAjTZAJ4pPwL2mljM9x01U97Fa+IqmQ2zPwCg9oC2 cyzkn8rqi5IbWHZ6bZZU/Zw= =caqj -----END PGP SIGNATURE----- **** DISCLAIMER **** "This e-mail and any attachment thereto may contain information which is confidential and/or protected by intellectual property rights and are intended for the sole use of the recipient(s) named above. Any use of the information contained herein (including, but not limited to, total or partial reproduction, communication or distribution in any form) by other persons than the designated recipient(s) is prohibited. If you have received this e-mail in error, please notify the sender either by telephone or by e-mail and delete the material from any computer". Thank you for your cooperation. For further information about Proximus mobile phone services please see our website at http://www.proximus.be or refer to any Proximus agent.
