GK
Вы описали пример на каком-то африканском языке. Я попытался как-то вывести Вас на диалог, но не получается.
Size: a a a
2019 December 12
AW
Вы описали пример на каком-то африканском языке. Я попытался как-то вывести Вас на диалог, но не получается.
Что именно на африканском? Обычная таблица из реляционной базы? Десериализация? Обьект? Тип? Фабрика?
Вполне простой пример.
Вполне простой пример.
GK
Опция это что? Опции в клиентском коде чего? Опция и фича это синонимы (Вы пишите, "опция равно какая-то фича")? Если синонимы, почему Вы говорите отдельно об опциях и фичах? Клиентский код по отношению к чему? Интерфейс для работы извне чего?
По второму примеру.
Что собой представляет конфигурация типа? Почему её нельзя получить с помощью рефлексии, чтобы потом использовать в фабриках и где угодно?
По второму примеру.
Что собой представляет конфигурация типа? Почему её нельзя получить с помощью рефлексии, чтобы потом использовать в фабриках и где угодно?
AW
Опция это что? Опции в клиентском коде чего? Опция и фича это синонимы (Вы пишите, "опция равно какая-то фича")? Если синонимы, почему Вы говорите отдельно об опциях и фичах? Клиентский код по отношению к чему? Интерфейс для работы извне чего?
По второму примеру.
Что собой представляет конфигурация типа? Почему её нельзя получить с помощью рефлексии, чтобы потом использовать в фабриках и где угодно?
По второму примеру.
Что собой представляет конфигурация типа? Почему её нельзя получить с помощью рефлексии, чтобы потом использовать в фабриках и где угодно?
AW
Фичи.
AW
Тип опции и фича - синонимы.
GK
Теперь всё понятно. Вы всё правильно делаете.
AW
Опция это что? Опции в клиентском коде чего? Опция и фича это синонимы (Вы пишите, "опция равно какая-то фича")? Если синонимы, почему Вы говорите отдельно об опциях и фичах? Клиентский код по отношению к чему? Интерфейс для работы извне чего?
По второму примеру.
Что собой представляет конфигурация типа? Почему её нельзя получить с помощью рефлексии, чтобы потом использовать в фабриках и где угодно?
По второму примеру.
Что собой представляет конфигурация типа? Почему её нельзя получить с помощью рефлексии, чтобы потом использовать в фабриках и где угодно?
Клиентский код по отношению к некой системе, которую я приводил в пример выше.
AW
Супер, спасибо)
d
Причем тут рефлекция? Каким образом имея поле "type" со значением "фича_1" мне рефлекция поможет вытащить конфигурацию для этого типа, вызвать фабрику каких-то обьектов, присущим этому типу (это реальный юс кейс, детали упускаются) или узнать, как и во что десериализировать данные из поля "data"?
Имея такие данные, каким образом мне десириализировать data в обьект типа LimitedOptionData для опций 1 и 3, и в обьект типа SectionedOptionData для опции 2?
Каким образом мне создать обьекты типа F1OptionPresenter для опций 1 и 3, и обьект типа F2OptionPresenter для опции 2?
Рефлекция тут ни при чем.
id | type | data
1 | f1 | 123
2 | f2 | {"sections": ["one", "two"]}
3 | f1 | 877
Имея такие данные, каким образом мне десириализировать data в обьект типа LimitedOptionData для опций 1 и 3, и в обьект типа SectionedOptionData для опции 2?
Каким образом мне создать обьекты типа F1OptionPresenter для опций 1 и 3, и обьект типа F2OptionPresenter для опции 2?
Рефлекция тут ни при чем.
Вижу вы начинаете строить key-value-attribute схему бд. Это антипаттерн. У вас база не нормализована, потом выборки не сможете делать и расширяемость будет страдать. Плюс исходный код начнет завязываться из-за бизнес требований на содержимое колонок типа вашей data, что ведёт к утечке контроля
d
То есть перед тем как начать работать собственно с данными у вас появляется шаг с получением метасхемы из бд, конструированием типов в рантайме, и только потом собственно полезная нагрузка. Последствий много.
d
Ну и в итоге ничего кроме монолита не получится построить, то есть теряете в гибкости дальнейшего развития. Или может каждому микросервисы свой key-value-attribute конструктор типов сделать? Или может сделать это отдельным микросервисом?) В общем губите гибкость
A
Ну и в итоге ничего кроме монолита не получится построить, то есть теряете в гибкости дальнейшего развития. Или может каждому микросервисы свой key-value-attribute конструктор типов сделать? Или может сделать это отдельным микросервисом?) В общем губите гибкость
Монолитность тут вообще не в тему как бы. Далеко не в каждом сервисе такой механизм нужен.
d
Возможно, но про будущее надо тоже думать
d
Ещё добавлю что в обозначенном случае логическая модель данных не совпадает с физической моделью данных. Дополнительная сложность понимания. Сапорту системы, равно её как и всем новым сотрудникам, потом обучение потребуется или детальная документация схемы.
d
Если все же продолжите в ту же сторону копать, то совет - перееедьте с рсубд на документное хранилище
GK
Вижу вы начинаете строить key-value-attribute схему бд. Это антипаттерн. У вас база не нормализована, потом выборки не сможете делать и расширяемость будет страдать. Плюс исходный код начнет завязываться из-за бизнес требований на содержимое колонок типа вашей data, что ведёт к утечке контроля
В данном случае автору вопроса нужно садиться и читать учебник по программированию, а потом по базам данных. Думаю, вряд ли кто-то даст лучший совет.
PD
Если все же продолжите в ту же сторону копать, то совет - перееедьте с рсубд на документное хранилище
При этом база данных может остаться той же, просто метод работы с ней поменяется.
PD
Нуу, с появлением jsonb осмысленность eav сильно уменьшилась.
GK
Игорь, почитай пожалуйста вопросы. По-моему очевидно, что нужно базу подводить. Я не шучу.