Поррассуждаем? Как лучше работать с парой связанных значений в классах? (например, nullable)

[mazzy]

Цитата:

Сообщение от Владимир Максимов

Возможные варианты:

угу. а еще есть? а можно всех посмотреть?

Цитата:

Сообщение от Владимир Максимов

Каким образом будет построен интерфейс с пользователем, чтобы пользователь мог понять, где значение будет интерпретировано как null, а где - как указанное значение? Пусть даже пользователь и "не трогал" этого значения. Или "потрогал", но вернул назад

Вот!
Для примера возьмем MS SQL и Аксапту 2012, которые умеют отображать null значение, полученное из базы. там в поле отображается специальное значение null, а поле становится недоступным для редактирования.

В аксапте 2012 со специальным значением напряжно. Но, думаю, что надо делать поле недоступным для пользователя.

Но, опять же, хотелось бы выслушать варианты.

Цитата:

Сообщение от Владимир Максимов

Вообще-то, мне приходит в голову только один вариант на подобный случай. Это когда речь идет о полях, которые пользователь изменить не может. Максимум посмотреть. Та же контрольная сумма. Но это значит, что речь идет о неких расчетных значениях, которые, очевидно, зависят от других реквизитов. Так может, можно эти самые "другие реквизиты" и использовать как признак значения NULL?

другие реквизиты могут находится за тысячу километров таблиц от данного места и метода, где пара значений применяется. я уже приводил примеры

"если для данного клиента включен контроль кредитного лимита, то спросить и хранить этот кредитный лимит"

Цитата:

Сообщение от Владимир Максимов

Очень ограниченно можно использовать (prmIsDefault() == 1) как признак того, что параметр передан не был. Т.е. интерпретировать это как передачу null.

не совсем.
чтобы срабатывал prmIsDefault в вызывающем классе параметр не должен быть указан.

если же у нас есть каскад методов с параметрами по-умолчанию, то параметр отсутствует только в самом внешнем. остальные передают тот параметр, который получили. и в каскаде prmIsDefaul сработает только один раз в каскаде.

Цитата:

Сообщение от Владимир Максимов

В среде Axapta значение NULL физически может быть сохранено в переменной типа ComVariant.

Ну... Насколько я помню он не pack/unpack-совместимый.
И как он передается между клиентом и сервером?

[Владимир Максимов]

Цитата:

Сообщение от mazzy

угу. а еще есть? а можно всех посмотреть?

Варианты хранения доп.признака в базе данных? Так вроде все перечислил. Ну, если не считать собственно поддержку NULL для поля. Или интересует вариант технической реализации? Так это у кого на что фантазии хватит. Например, для хранения признака создавать не по отдельному полю для каждого поля с возможным NULL, а одно общее поле, где хранить битовую маску...

Ну, и уже упоминались варианты, когда значение, эквивалентное NULL не надо прятать, а наоборот, выставить как одно из возможных значений.

Например, заменить CheckBox на ComboBox с 3 вариантами выбора (All / Yes / No). Для текста (кода справочника) создать специальный элемент справочника с пустым кодом.

Цитата:

Сообщение от mazzy

Вот!
Для примера возьмем MS SQL и Аксапту 2012, которые умеют отображать null значение, полученное из базы. там в поле отображается специальное значение null, а поле становится недоступным для редактирования.

Как мне кажется, это не правильное решение разработчиков. Ведь получается, что если поле приняло значение null, то пользователь его не может изменить напрямую. Чтобы пользователь смог изменить это поле, его значение должно быть программно установлено в пустое значение. Фактически, создается доп.поле, содержащее признак необходимости изменить основное поле. Что возвращает к реализации с двумя полями.

Цитата:

Сообщение от mazzy

другие реквизиты могут находится за тысячу километров таблиц от данного места и метода, где пара значений применяется. я уже приводил примеры

"если для данного клиента включен контроль кредитного лимита, то спросить и хранить этот кредитный лимит"

Опять я не в курсе "новых веяний" в Ax2012, но в младших версиях Axapta все ключевые реквизиты, необходимые для расчета копировались в подчиненные и связанные таблицы. Т.е. находится за тысячу километров таблиц он не должен. Это ошибка проектирования (хотя и нарушает принципы нормализации)

В данном примере, где будет хранится сумма кредитного лимита? Ну, предположительно, либо в таблице клиента, либо в таблице договоров. В обоих случаях признак контроля кредитного лимита должен быть в той же таблице.

Цитата:

Сообщение от mazzy

не совсем.
чтобы срабатывал prmIsDefault в вызывающем классе параметр не должен быть указан.

Угу. Так я так и написал "очень ограниченно" Т.е. в очень специфических ситуациях.

------------------

Если просто "перечислять варианты", то вот еще парочка идей

1. Объект Map из одного элемента: ключ - признак NULL, значение - значение
2. Объект Struct из одной "строки". Одно "поле" - признак NULL, другое - значение. Если добавить 3 поле-идентификатор, то можно в один объект Struct собрать все переменные для обработки, сделав несколько "строк". Аналог временной таблицы
3. Объект Set или List из одного элемента. В случае, если значение эквивалентно NULL, то не создавать (или удалять) элемент. Нет элементов - значение NULL

Эти объекты позволяют сделать частичный контроль типов (правда, только на уровне базовых типов), а также имеют встроенные методы pack/create, что упрощает их передачу в pack/unpack