ActiveRecords и поля таблиц, где идеал?

Question

[jimmi]

Имеется php класс для работы с БД, каждый класс имеет список полей текущей таблицы в таком виде

protected $_row = array(
   'id' => true,
   'name' =>true,
   'surname'=>true     
);

Этот список полей применяется чтобы отсеять кривые данные при вызове функции ->save();
Также при использовании ничего не может быть проставлено лишнего, чего нету в переменной $_row

Теперь ситуация когда этому классу нужно передать какой-то ключ через setter не входящий в золотой список row, или когда нужно сделать ->get('some LEFT JOIN field'), т.е. получить это поле нету возможности так как оно не входит в массив row.
Проблема решена добавление дополнительного массива по типу

// list of extended fields
	protected $_moreDataList = array(
		'field' => true,
		'field1' => true,
		'field2'  => true
	);

Тем самым если мы выбрали в этом классе с помощью LEFT JOIN какие-то дополнительные поля которых нету в переменной $_row то мы их все равно может получить через ->get так как они входят в дополнительную переменную. Почему дополнительная? потому что при save() нам все равной придется отсеять лишнее.

Теперь вопрос. Нужно ли вообще фильтровать get и set наружу с класса? Или достаточно просто фильтровать тот же save() метод и не указывать дополнительные поля. Т.е. избавить себя от геморроя постоянного вписывания этих доп. полей когда делаешь какой-то JOIN не связанный с таблицей класса. А то сделал селект поля field2 через JOIN , смотришь в get('field2') а там пусто. Ааа.. точно, надо ж добавить его в "_moreDataList".

Заранее спасибо за помощь.

Answer 1

[Ширшов Александр]

Чтобы сразу несколько полей задать/получить, можно написать методы с фильтрацией, лишние данные где-то хранить совершенно незачем. И от set('filedName') нужно избавляться в сторону setFieldName() и при возможности использовать их. В zf для заполнения объектов есть удобная вещь - zf2.com.ua/doc/65 можно использовать этот подход

Comments

[jimmi]

Спасибо, все же нету смысла хранить имена дополнительных полей раз они все равно фильтруются при передаче DB запросам(->save() фильтрует).

[jimmi]

Также имея в базе 30+ полей на каждой таблице, делать из set('filedName') setFieldName() думаю пустая трате методов. Т.е. таким образом класс будет иметь в основном методы для установку полей и через них уже и не будет видно самой функциональности класса + это получится тот же тотальный контроль входных и выходных данных что добавляет еще больше проблем чем я описывал выше.
Ведь в теории нету ничего плохого(наверно) что внешний мир может проставлять и получать любые данные в массиве $data который находится в AR классе и данные которого фильтруются при сохранении в базу НО при возврате данных с Join'ами ненужно делать дополнительных манипуляций с прописыванием полей которые появились.

Хотя, возможно есть некая ценность что возможно описанные в начале класса дополнительные поля который он возвращает позволит вспомнить что этот класс работает не только с полями текущей таблицы а еще что-то там JOIN'инть, поправьте если неправ.

[Ширшов Александр]

Немного не по сути вопроса: Я заместо active records использую orm, там это решается проще, там таблицы отражены через классы (св-ва классов). Возможно вам это поможет. odiszapc.ru/doctrine
При join ты получешь полноценный объект с которым можно работать так, как будто ты изначально только его выбрал.

[jimmi]

Да, возможно отображение и лучше будет в плане быстроты набора кода и легкости с ним управления. Да вот только у нас в проекте слишком уж большой этот монстр доктрина будет. Проще(в плане быстродействия системы) использовать крайне легкий AR и велосипедом вроде конструктора запросов. В доктрине второй просадка скорости по сравнению с PLAIN SQL может быть в 3 раза иногда но и использовать PLAIN SQL тоже не особо хочется, вот и приходит крутится как-нибудь.
Но в проектах где быстродействие не так важно конечно доктрина хороший выбор.