а для отдельного поля можно сделать так
function __call($name, $arguments){
$nameField = str_replace("valid", "", $name);
if(isset($this->$aDataField[$nameField])){
$func = 'validate'.$this->aDataField[$nameField];
// поехали
if($this->$func($arguments)){
// для поля $key валидация пройдена
}else{
// для поля $key валидация не пройдена
}
}
}
т.е. просто вызываешь
$myclass->validfield1($val);
$myclass->validfield2($val);
$myclass->validfield3($val);
подобное решение допустимо?
т.е. получается не нужно отдельно прописывать спец функцию валидации для отдельного поля достаточно указать тип его валидации или все же задать спец функцию, что бывает крайне редко допустим если это многомерный массив
| Цитата (Guest @ 29.01.2019 - 00:30) |
| Рон, а если свойств объекта 50? Магазин запчастей к примеру |
Какие запчасти ты имеешь ввиду? Например я, как опытный автолюбитель, прото не представляю неделимую автозапчасть с таким количеством свойств с точки зрения программирования. Давай поговорим на примере авто. У объекта запчасти всего лишь несколько свойств, среди которых номер по каталогу производителя, и цена. Или ты думаешь приходит человек в магазин и начинает выбирать фильтрами шкив распредвала? Типа, количество зубьев такое-то, шпоночный паз такой-то, всевозможные диаметры и прочее? Нет конечно же. Таких магазинов автозапчастей не существует в природе, только если конкретно специализируется на определенном типе запчастей (или нескольких). Скажем, магазин свечей зажигания, тогда да, но там не будет 50 свойств тоже. С десяток может быть. Ну да, буду прописывать свойства сущности вручную, а как же? =) Если речь о более крупных (составных запчастях) и в этом есть смысл, тогда делается через агрегат.
Или магазин радиодеталей, где фильтры строго обязательны, иначе ничего не найдешь. Это? Там под каждый тип заводится своя сущность: резисторы одна, конденсаторы - другая. У них разный набор свойств и снова их далеко не 50. =) Указываются только основные, по поводу полных и точных характеристик тех же полупроводниковых приборов (стабилизаторы, транзисторы и более сложные) людей отправляют читать datasheet.
Но 50 свойств в одном объекте у тебя значит полный ппц с архитектурой. Это образно говоря тоже самое (а во многих фреймворках буквально тоже самое), как 50 полей в таблице БД. =)
сущность: резисторы одна, конденсаторы - другая.
это вообще могут быть категории, но это не важно
Но 50 свойств в одном объекте у тебя значит полный ппц с архитектурой. Это образно говоря тоже самое (а во многих фреймворках буквально тоже самое), как 50 полей в таблице БД. =)
1) не зависай на этом у клиента бзиг хочет 50 свойств товара, что делать , как добавлять?
2) можно ли через такие решения?
$func = 'validate'.$this->aDataField[$nameField];
// поехали
if($this->$func($arguments)){
я не ищу поддержки своей темы , мне нужно понять корректно ли такое решение и если нет то почему
| Цитата (Guest @ 29.01.2019 - 01:02) |
| в данной конструкции если нужно добавить новое свойство объекта для валидации достаточно указать его в массиве $aDataField и указать значение - тип проверки - такое решение корректно? |
Если myclass и есть сущность, я считаю что да, в простом варианте так норм. Описание типа свойств должно храниться в самом классе, в любом случае.
Другое дело не согласен с собственной реализацией валидатора, нужно взять готовую библиотеку. Либо, если так хочется самому писать валидатор, то выделить его в отдельную подсистему, то есть проще говоря в библиотеку, только собственную.
И по вызову тоже странно, сначала делается запись данных в объект, потом его валидация. Не наоборот, по причине что подготовка к валидации может потребовать дополнительных действий. В случае отдельных сеттеров прямо в них, для чего они и служат. Если как мой вариант, тогда отдельный метод, который будет вызываться перед валидацией.
| Цитата (Guest @ 29.01.2019 - 01:49) |
| это вообще могут быть категории, но это не важно |
Категории это уже каталог, там другое. Категория состоит из сущностей, тут не агрегат а композит. К примеру полупроводники - категория. Она состоит из сущностей: стабилизаторы, диоды, транзисторы и т.д. Либо категория может состоять из подкатегорий.
| Цитата (Guest @ 29.01.2019 - 01:49) |
1) не зависай на этом у клиента бзиг хочет 50 свойств товара, что делать , как добавлять?
|
Одна из задач программиста убедить клиента сделать технически грамотно. А если он настаивает, то предупредить что получится плохо, и со спокойной душой делать как на руку ляжет. Повторюсь, если 50 полей в БД - ОК, значит и 50 свойств в классе тоже ОК. Ты же прописываешь их вручную, когда создаешь таблицу?
Одна из задач программиста убедить клиента сделать технически грамотно. А если он настаивает, то предупредить что получится плохо, и со спокойной душой делать как на руку ляжет. Повторюсь, если 50 полей в БД - ОК, значит и 50 свойств в классе тоже ОК. Ты же прописываешь их вручную, когда создаешь таблицу?
Рон, понимаешь вот в этом и косяк, тебе может достаться нечто... то с чем работали 20 человек до тебя или cms где поля для товара добавляются через админку и автоматом идут в бд или вызов классов и модулей реализован через ноги в рот- понимаешь у меня вот ступор возникает, я могу понять что на паттернах нужно проектировать архитектуру, но вот править паттернами что-то такое это сложновато для моего понимания =(
Быстрый ответ:
Powered by dgreen
Здесь расположена полная версия этой страницы.