bars80081
Новичок
Добрый день,
есть потребность в одной стандартной реализации (с которой, как я думаю, работает большинство), но не могу никак нормально гугел спросить. Всё подсовывает ссылки на генерацию сущностей, либо реализацию мультиязычности, либо просто словарь терминов. Прошу направить в нужное русло.
Есть потребность в СЛОВАРЕ - небольшой массив данных, который не имеет смысла реализовывать в виде таблицы в БД.
Пример:
допустим, у таблицы orders есть поле status int. В нём хранится значение 0, 1, 2, 3... , которое означает NEW, CANCEL, SELL, REFUND... . На странице заказа требуется выводить соответствующее значение "новый", "аннулирован", "продажа", "возврат"... , на странице списка заказов требуется выводить селектор для фильтрации, в API следует при выгрузке заказа выдавать соответствующее кодовое слово NEW, CANCEL, SELL, REFUND, а в выгрузке API по стандарту ГОС-ШМОС-ТЕЛЕРАДИО ОТ, АН, ПД, ВЗ.... и так далее.
руки чешутся написать два базовых класса Dictionary и DictionaryItem для реализации функционала и наследоваться от них для каждого случая словаря. В духе:
в конечном счёте это нам должно дать центральное хранилище для словаря, готовые фукции получения нужного кода по каком-то входящему параметру, готовые списки и удобное использование. к примеру, сущность Order можно было бы связать так, чтобы в twig вставлять требуемое значение без лишних действий {{ order.status.title_ru }}.
Почему не сделать такой словарь в виде таблицы в БД и не приложить к ней соответствующую сущность и репозиторий?
как-то кажется, что слишком жирно. словарь - это не данные, обновление или дополнение - практически никогда. зачастую имеет ничтожный перечень значений. обращаться в БД по такому случаю, городить здоровые сущности на каждый чих - как-то перебор. на практике, в моих проектах, в среднем на каждую сущность может потребоваться два-три словаря. хотя некоторые словари повторяются (к примеру, статус активности), но иметь ради таких маленьких перечней лишние 200-400 таблиц в БД как-то непонятно зачем.
в общем, написать не проблема. однако, прежде чем начну делать свой глючный велосипед, который потребует доводки на практике, наверняка это уже реализовано где-то с очень хорошим функционалом. в конце концов, зачем я использую Симфони, как не ради множество уже написанных фичей?
нету ли у вас на примете чего-то похожего и уже реализованого?
может уже встроено в Симфони?
или я в чём-то кардинально не прав?
есть потребность в одной стандартной реализации (с которой, как я думаю, работает большинство), но не могу никак нормально гугел спросить. Всё подсовывает ссылки на генерацию сущностей, либо реализацию мультиязычности, либо просто словарь терминов. Прошу направить в нужное русло.
Есть потребность в СЛОВАРЕ - небольшой массив данных, который не имеет смысла реализовывать в виде таблицы в БД.
Пример:
допустим, у таблицы orders есть поле status int. В нём хранится значение 0, 1, 2, 3... , которое означает NEW, CANCEL, SELL, REFUND... . На странице заказа требуется выводить соответствующее значение "новый", "аннулирован", "продажа", "возврат"... , на странице списка заказов требуется выводить селектор для фильтрации, в API следует при выгрузке заказа выдавать соответствующее кодовое слово NEW, CANCEL, SELL, REFUND, а в выгрузке API по стандарту ГОС-ШМОС-ТЕЛЕРАДИО ОТ, АН, ПД, ВЗ.... и так далее.
руки чешутся написать два базовых класса Dictionary и DictionaryItem для реализации функционала и наследоваться от них для каждого случая словаря. В духе:
PHP:
class Dictionary {
protected static $data = [];
protected static $itemClass;
public static function get($search, $by = 'id') {
foreach(self::$data as $item) {
if(isset($item[$by]) && $item[$by] == $search) {
return new $itemClass($item[$by]);
}
}
return new $itemClass();
}
public static function getList($by) {
$data = [];
foreach(self::$data as $item) {
if(isset($item[$by])) {
$data[] = $item[$by];
}
}
return $data;
}
// разные полезные методы
}
class DictionaryItem {
public function __construct($data) {
if(!empty($data)) {
foreach($data as $key => $v) {
$this->set($key, $v);
}
}
}
// методы реализующие динамическое построение геттеров и сеттеров
}
class OrderStatusDictionary extends Dictionary {
protected static $data = [
[
'id' => 0,
'code' => 'NEW',
'title_ru' => 'новый',
'GOS_SHMOS' => 'ОТ',
],
[
'id' => 1,
'code' => 'CANCEL',
'title_ru' => 'аннулирован',
'GOS_SHMOS' => 'АН',
],
...
];
}
class OrderStatusDictionaryItem extends DictionaryItem {
protected $id = -1;
protected $code = '';
protected $title_ru = '';
protected $GOS_SHMOS = '';
}
Почему не сделать такой словарь в виде таблицы в БД и не приложить к ней соответствующую сущность и репозиторий?
как-то кажется, что слишком жирно. словарь - это не данные, обновление или дополнение - практически никогда. зачастую имеет ничтожный перечень значений. обращаться в БД по такому случаю, городить здоровые сущности на каждый чих - как-то перебор. на практике, в моих проектах, в среднем на каждую сущность может потребоваться два-три словаря. хотя некоторые словари повторяются (к примеру, статус активности), но иметь ради таких маленьких перечней лишние 200-400 таблиц в БД как-то непонятно зачем.
в общем, написать не проблема. однако, прежде чем начну делать свой глючный велосипед, который потребует доводки на практике, наверняка это уже реализовано где-то с очень хорошим функционалом. в конце концов, зачем я использую Симфони, как не ради множество уже написанных фичей?
нету ли у вас на примете чего-то похожего и уже реализованого?
может уже встроено в Симфони?
или я в чём-то кардинально не прав?