|
![]() |
#1 |
Участник
|
Да... это частный случай
![]() я как раз не хотел бы сводить к этому частному случаю. а хотел бы порассуждать в целом. да, костыли лепить придется. но соображения такие: = отображение - это семейство методов/классов. = поэтому удобнее отображать там, где пара связанных объектов передается как она сущность. = но при этом способ должен быть таким, чтобы не насиловать среду разработки. например, объект класса - в текущей версии удобно передавать как параметр в методы, но неудобно встраивать в pack/unpack. |
|
![]() |
#2 |
Участник
|
Я бы выбрал гибрид способа 2 и... 3, который создание класса (нумерация немного того). В базе храним парой разных полей (альтернатив здесь вообще говоря особо и нет). В всех остальных местах - классом. В RunBase и прочих подобных сценариях можно использовать как класс, так и пару переменных. Там с отдельным классом неудобство только одно - распаковку приходится делать через промежуточную переменную - контейнер. И кстати, вот неявно цепляется и "контейнерный" способ. При передаче можно задействовать и его, как только понадобится что-то более серьезное - проверка, сериализация и т.п. - быстренько его Tuple::create(packedTuple) и работаем с удобным классом.
В общем, если сложить плюсы и сократить минусы - то минусов как бы и не остается. |
|
Теги |
null, nullable, tuple, как правильно |
|
|