I totally agree on what you've said. The problem is that most programmers confuse DB Abstraction Layers, with Database Wrappers. There are many approaches to simplify, unify & extend Database functionality. I generally think a DB Abstraction Layer is very useful if you're developing a *product* that needs to run with different databases. Managing the differences in SQL dialects is a nightmare! I would rather use some sort of a layer to handle that, and I certainly wouldn't write my own, unless I know exactly why I need to do that.
As far as I know, MDB2 & ADOdb are the two most mature, full fledged abstraction layers out there. That said, it doesn't mean you shouldn't abstract Data Access (Models). Abstracting data from the application is a must, in MVC terms, that would be writing models. You can still write excellent models using native DB functions, e.g. mysql_* - Ammar On 10/17/07, zaid emeish <[EMAIL PROTECTED]> wrote: > > > Ok. for a start. there are no rules in programming. there are only guide > lines. so if you are looking to use a DB layer. you should ask urself a few > questions: > 1- Do I really need a DB layer? > 2- If Do I use one. is it gonna make my job easier? > 3- What exactly do I want this layer to do? --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Jordan PHP Users Group" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/JoPHP http://Jolug.org/ -~----------~----~----~----~------~----~------~--~---
