Не так давно, при написании демонстрационного приложения для своего php фреймворка, у меня появилась задача - обеспечить работу с базой данных. Передо мной было два варианта решения:
- Написание собственной библиотеки;
- Использование уже готовых решений;
Фи, подумал я, что такого написать класс обвертку над PDO, как два пальца об асфальт. После чего был выбран первый вариант.
Кратко опишу, что я хотел от собственной библиотеки.
- Создание и обновление таблиц в базе данных на основе схемы метаданных.
- Свой формат метаданных для описание схемы базы данных.
Начав писать свой скрипт, я начал осознавать, что мне придется не хило огребать и тратить кучу времени на его поддержку. Такая ситуация меня совсем не устраивала, поэтому пришлось перейти ко второму способу решения задачи - использованию готовых решений.
Я выбрал Doctrine 2, потому что она решала все задачи, которые я ставил перед своим велосипедом. Но это был достаточно сложный выбор, по нескольким причинам:
Я выбрал Doctrine 2, потому что она решала все задачи, которые я ставил перед своим велосипедом. Но это был достаточно сложный выбор, по нескольким причинам:
- Это довольно тяжелый инструмент, который ухудшает производительность приложения.
- У Doctrine есть свой собственный API, под который нужно подстраиваться.
- Doctrine не на столько гибка как хотелось бы.
Но, все эти минусы перечеркивал только один аргумент - мне не нужно писать столько кода. Да и по прошествии 5 часов её изучения, я стал относиться к ней не так критично.
К чему этот пост?
Всегда Иногда бывает выгодно использовать уже готовые решения, а не писать велосипеды. И перед тем как вы начнёте писать свой велосипед, все таки подумайте - сколько вы будете писать, есть ли аналоги, будет ли ваш велосипед быстрее и лучше. Возможно будет легче адаптировать чьи-то наработки, а не писать всё с нуля.