# Koenig (28.12.2015 / 03:12)а зачем сеттеры дергать? Я считаю, что сущности должны иметь публичную область видимости для своих свойств, которые заполняются с помощью fetchObject. Другими словами ничего плохого в том, что свойства сущности public, ведь на то есть одна довольно весомая причина: попробуй реализовать крупный проект на базе ORM с закрытыми (private) свойствами. Очень быстро ты заметишь, что все эти свойства сопровождаются геттерами и сеттерами (на пример getLogin, setLogin). Так же в этих методах в большинстве случаев не будет ничего, кроме прямого обращения к свойству. И становится непонятно, а зачем вообще их инкапсулировать, если к ним открыт прямой доступ? Раньше я занимался коммерческими проектами на Java, на базе одной платформы. Так там даже в документации было сказано: чтоб создать сущность, определите класс, его свойства, и getters/setters всех свойств ))
Delphinum, в mysql(i) тоже фетч в объект есть. даже когда то хотел присобачить к шаблонизатору. эта штука мне сразу приглянулась и не даёт покоя. было бы круто если сеттеры сам фетч дергал, а не прос
Иногда доступ к свойствам сущности через getters/setters полезен, на пример, когда установка значения свойства должно сопровождаться какими то перерасчетами, но это очень редкое явление и решается достаточно просто - реализацией дополнительного метода, занимающегося этими перерасчетами. На деле такое решение более краткое, чем десяток getters/setters методов в классе.
Позже я проникся философией BackboneJS и прицелом на JSON для обмена данными с RESTful API сервером. Тогда я еще больше полюбил простые, открытые сущности. С тех пор данные из базы хранятся у меня в сущностях с открытыми свойствами. Пусть это нарушает инкапсуляцию и адепты ООП плюются, но мне это удобно в использовании и просто в реализации.
Что касается шаблонизатора, описанный мной выше подход вообще позволяет передавать в шаблон целые сущности без необходимости как то их подготавливать (как нить доберусь и до этого вопроса в теме про Bricks).