Rammstein
PHPClub::News
Куда переносить логику проверки валидности значения: Domain Object или Unit Of Work
Существует такая система: Domain Object (его же можно назвать хранимым объектом; DO) отображается на БД через Data Mapper. При этом, дабы сократить количество обращений к БД, существует UnitOfWork, который следит за изменением всех DO и в конце транзакции в пакетном режиме закрепляет изменения в БД (одним большим запросом).
Коротко и грубо о принципе отражения DO на БД. У DO есть свойства, которые по схеме перекачёвывают в поля таблицы. Так вот, значение свойств требует предварительной проверки на валидностью (типа XSS и прочее). Проблема заключается в выборе места проверки полей. Есть два варианта:
а) В самом объекте в методе __set()
б) В UnitOfWork перед самым внесением изменений
Недостаток a) в том, что не сохраняется принцип Domain Model, т.к. потребуется отказаться от явного указания свойств. Так же я вижу определённые проблемы с производительностью (обращение через __get() потребует большего времени, чем прямое).
Но в отличии от a) , в б) сложнее контролировать изменения DO (потребуется каким-то образом сравнивать состояние в начале транзации и текущее, например, путём создания копии DO при инициализации)
Если это важно, то сам контроль валидности значения происходит в Field::is_valid($value). Вопрос только в том, когда это делать.
Из своих рассуждений:
Вероятно потребуется не более одного раза за транзакцию устанавливать новое значение свойства у DO, но считывать очень часто. Вопрос только в том, насколько обращение через __get() (при условии, что там только "return $this->fields[$name]") медленней прямого обращения к свойству.
Так же естественно, что если хранить копию DO, то расход памяти увеличится в два раза, да и операция сравнения двух объектов не самая быстрая.
Помогите решить: выделять проверку валидности свойства в UnitOfWork или же в DO::__set()
Существует такая система: Domain Object (его же можно назвать хранимым объектом; DO) отображается на БД через Data Mapper. При этом, дабы сократить количество обращений к БД, существует UnitOfWork, который следит за изменением всех DO и в конце транзакции в пакетном режиме закрепляет изменения в БД (одним большим запросом).
Коротко и грубо о принципе отражения DO на БД. У DO есть свойства, которые по схеме перекачёвывают в поля таблицы. Так вот, значение свойств требует предварительной проверки на валидностью (типа XSS и прочее). Проблема заключается в выборе места проверки полей. Есть два варианта:
а) В самом объекте в методе __set()
б) В UnitOfWork перед самым внесением изменений
Недостаток a) в том, что не сохраняется принцип Domain Model, т.к. потребуется отказаться от явного указания свойств. Так же я вижу определённые проблемы с производительностью (обращение через __get() потребует большего времени, чем прямое).
Но в отличии от a) , в б) сложнее контролировать изменения DO (потребуется каким-то образом сравнивать состояние в начале транзации и текущее, например, путём создания копии DO при инициализации)
Если это важно, то сам контроль валидности значения происходит в Field::is_valid($value). Вопрос только в том, когда это делать.
Из своих рассуждений:
Вероятно потребуется не более одного раза за транзакцию устанавливать новое значение свойства у DO, но считывать очень часто. Вопрос только в том, насколько обращение через __get() (при условии, что там только "return $this->fields[$name]") медленней прямого обращения к свойству.
Так же естественно, что если хранить копию DO, то расход памяти увеличится в два раза, да и операция сравнения двух объектов не самая быстрая.
Помогите решить: выделять проверку валидности свойства в UnitOfWork или же в DO::__set()
