Духовность™
Продвинутый новичок
какой смысл использовать ООП в php без ORM?
Собственно, сабж. Переходя на ОО-модель (тут под определением ОО-модель я говорю именно о тех объектах, которые создаются/обновляются на базе данных из СУБД) сталкиваешься с очень нетривиальной задачей, которая опрокидывает в парадокс весь смысл использования ООП - это трудность совместить объекты и реляционные модели. На тривиальных запросах и выборках всё достигается путём использования небольших самописных мапперов, имеющих вид зачатка ORM-системы. Но как только задачи становятся всё более и более сложнее, как только объекты начинают быть вложенными, многоуровневыми, а запросы связанными с помощью JOIN, то тут в буквальном смысле слова наступает полный, безоговорочный, не подлежащий лечению ПИСЕЦ.
Сам я столкнулся с тем, что использование ОО-программирования и реляционной модели вынуждает писать кучу слоёв приложения, которые при "стандартном" подходе с использованием обычного SQL и процедурного программирования сокращали бы в сотни раз строки кода, время, затраченное на разработку, но приводили бы код приложения к более "некрасивому" виду.
Посмотрел я доки той же доктрины и офигел только от самой документации, а что там внутри и представить сложно, гыгы.
Так вот, я теперь считаю, что использование ООП (в PHP) без ORM, это по сути дело тупиковое и в некоторой степени гиблое. Т.е. PHP в основном взаимодействует с реляционной базой, откуда и растут все сложности. Использование ООП в JavaScript, например, мне куда более удается - там нет необходимости писать объекты в хранилище и использовать SQL как метод получения данных, я оперирую объектами в памяти.
Я прав или нет?
Собственно, сабж. Переходя на ОО-модель (тут под определением ОО-модель я говорю именно о тех объектах, которые создаются/обновляются на базе данных из СУБД) сталкиваешься с очень нетривиальной задачей, которая опрокидывает в парадокс весь смысл использования ООП - это трудность совместить объекты и реляционные модели. На тривиальных запросах и выборках всё достигается путём использования небольших самописных мапперов, имеющих вид зачатка ORM-системы. Но как только задачи становятся всё более и более сложнее, как только объекты начинают быть вложенными, многоуровневыми, а запросы связанными с помощью JOIN, то тут в буквальном смысле слова наступает полный, безоговорочный, не подлежащий лечению ПИСЕЦ.
Сам я столкнулся с тем, что использование ОО-программирования и реляционной модели вынуждает писать кучу слоёв приложения, которые при "стандартном" подходе с использованием обычного SQL и процедурного программирования сокращали бы в сотни раз строки кода, время, затраченное на разработку, но приводили бы код приложения к более "некрасивому" виду.
Посмотрел я доки той же доктрины и офигел только от самой документации, а что там внутри и представить сложно, гыгы.
Так вот, я теперь считаю, что использование ООП (в PHP) без ORM, это по сути дело тупиковое и в некоторой степени гиблое. Т.е. PHP в основном взаимодействует с реляционной базой, откуда и растут все сложности. Использование ООП в JavaScript, например, мне куда более удается - там нет необходимости писать объекты в хранилище и использовать SQL как метод получения данных, я оперирую объектами в памяти.
Я прав или нет?
Ему бы сначала основные проблемы хотя бы в википедии почитать =)
Вот например гугловский bigtable с его ограничениями намного лучше ложится на ORM, и там до распределенного объектного хранилища вобщем то один шаг.