Don't blindly adopt or write a wrapper just because "most people say it is not a good practice" to use DBI directly. What do you think the wrapper should do? Wrapping DBI just because "wrapping is good" is plain nonsense. For small CGIs that each just does one little thing with the Database, direct access via DBI may be the best implementation. Wrapping has a cost, usually it slows down things. If you build a big project, plan to store objects in an RDBMS, need to work with a dozen RDBMS, and so on, a wrapper may be a good idea. The wrapper could take care of SQL and meta-data differences, and an object relational mapper (ORM) could act as a wrapper removing the need to manually serialise and deserialise the objects, generating SQL automatically, and so on.
Alexander
--
Today I will gladly share my knowledge and experience, for there are no sweeter words than "I told you so". ;-)
| [reply] |
I agree with afoken - don't wrap unless you know exactly why you should wrap, and to which effect.
Remember that DBI already is a wrapper, and abstracts away most database specific code (ie communication with the database server).
That said there are many extensions and wrappers on CPAN already, mostly in the DBIx:: namespace. | [reply]
[d/l] |
As others have said already - don't leap into using a wrapper if you don't need it. Do make sure you use DBI safely though, make sure you sanitize your input (DBI Parameter Security), etc.
If you do want to look at a wrapper, then I'm very fond of DBIx::Class which is a thing of beauty.
| [reply] |
| [reply] |