I am considering building a DBAL from scratch with PHP to use within my projects and also to learn through the process.
I have noticed on SO and other reputable forums that whenever this is mentioned most users advise to use an established DBAL like Doctrine and to not “reinvent the wheel“.
Why is it that with this specific piece people continuously recommend to use a pre-made one? Is it that hard/problematic to create and build as you go? If so what are the main problem points? I assume security is one.
In regards to the established DBALs like Doctrine, I have downloaded and inspected the contents and noticed its rather big, for those who have experience with this, is all of this really necessary? Do you use all of this functionality provided(and know whats happening in the backend)?
From what I inspected I am finding it hard to see how I would use more than 40% of the libary, along with this I have the feeling that I am not completely sure whats happening in the backend with such a big library. Perhaps this is a common feeling and you get over it?
3
- You have a need,
- There is a library which fulfills your need,
- The library is free, so the only cost is the time you’ll spend learning how to use it,
- And you might be using up to 40% of this library.
How long is to learn how to use something like Doctrine? I’d say ten minutes for most basic scenarios, and up to an hour for more advanced stuff.
How long is to reinvent the wheel, i.e. write a similar library (minus 60% of its features you don’t need), which means:
- Creating the architecture and the design,
- Writing enough tests to be sure it works correctly,
- Writing code,
- Handling edge cases,
- Writing documentation,
- Refactoring the code in order to be able to maintain it later,
- Having a long-term commitment of maintaining the library for several years?
If you’re a really fast and smart developer and you’re able to do the first six steps in ten minutes, go for it. Go for it as well if you want to learn how ORMs are built (although there may be better ways to learn about ORMs).
But if you should deliver working software on time and within budget, reinventing an ORM without a very good reason wouldn’t be a wise choice.
1