Цитата:
Сообщение от
mazzy
1. AXSerializer использует рефлекшн, чтобы получить название парм-методов. Рефлекшн в аксапте - медленный. что с производительностью?
Наверное, не так быстро, если бы это был не рефлекшен. Но я не тестировал, в моём случае нагрузка не высока.
Цитата:
Сообщение от
mazzy
2. AXSerializer кэширует инфо о классах в infolog.globalCache. Каков обычный размер кеша для обычного инстанса него и что со сборкой мусора, когда в перманентном кэше столько объектов?
А как измерить размер кэша? В кэше список методов класса-контракта и соответсвующие им названия пропертей в XML\JSON. Чем больше контракт тем больше кэш. Мусор убираю не я, но должен сам читститься по прекращению сессии, что эквивалентно сеансу обмена. Не проверял - не интересно, не думаю что это проблема.
Цитата:
Сообщение от
mazzy
2. AXSerializer кэширует инфо о классах в infolog.globalCache. Каков обычный размер кеша для обычного инстанса него и что со сборкой мусора, когда в перманентном кэше столько объектов?
Цитата:
Сообщение от
mazzy
3. метод constructDCProperty пытается разобрать второй параметр в парм-методах. в примере вижу только null в этом параметре. подозреваю, что параметр определяет только тип содержимого в списке. а что там может быть и зачем этот второй параметр?
Всё верно. Исключительно для подсказки сериализатору - какого типа объект в списке. Хочется это запихнуть в псевдо-аттрибут (макрос сверху метода), но т.к. этот макрос, по сути просто комментарий, то а) в случае неверного написания не получим compilation error б) не увидим использование этого типа в CrossRef
Цитата:
Сообщение от
mazzy
4. вижу что у парм-методов первой строкой что-то вроде атрибута метода. но не понял как этот псведо-атрибут используется в проекте. можешь рассказать что это, где и как используется?
Это и есть аттрибут, в моём исполнении для AX2009. Сериализатор сканирует все поля контракта на предмет наличия этого аттрибута, тем самым понимая, какие поля нужно сериализовать и извлекает названия этих полей. Эту информацию он заталкивает в мапу и кэширует, чтобы не сканировать source code повторно. Вероятно, следовало бы макрос сделать чуть более похожим на настоящий атрибут в AX2012, с точки зрения синтаксиса, дополнив возможность указывать тип ы коллекций или просто тип, но см. п.3 выше.
Цитата:
Сообщение от
mazzy
5. тебе не кажется, что предположение о parm-методе слишком жесткое? может стоило разбирать тип возвращаемого значения и типы параметров метода? все равно ж далее по коду они анализируются.
Да, можно было бы эту жесткость убрать, т.к. п.4. это компенсирует. С другой стороны - тогда придется просканировать SourceCode абсолютно всех методов, что немного увеличит время холодного старта.
Цитата:
Сообщение от
mazzy
6. вижу, что коллекции - это тольео List и Array. Почему нет Set, Struct? и почему не потомки? (== вместо is). И почему не контейнер? это просто так исторически сложилось или ограничение движка? а какое?
List и Array вполне хватает. Даже одного List хватает. Если же тему развивать, то почему бы туда не добавить возможность сериализовать, скажем, FormRun, разложив её вплоть до пропертей контролов?
Цитата:
Сообщение от
mazzy
7. И да. На что бы ты сам посоветовал обратить внимание в проекте?
Что я там не дожал в части XML - это продумать\привести в порядок названия узлов. Сейчас там можно встретить такие методы, как GetElementName, GetRootName. С одной стороны - это опять же можно воткнуть в аттрибуты. С другой стороны - хотел, чтобы сериализатор работал со стандартным AIF AX2009 (Если помнишь, стандарт умеет серилизовывать только Document-Services, когда как для CustomServices правила сериализации и XSD приходится хардкодить самому, что то ещё удовольствие). Так вот GetElementName\GetRootName нужны именно для AIF + все мои контракты наследуются от XMLSerialisable, что опять же нужно для AIF. В результате - эту чуть нужно бы проверить\пересмотреть. На чём я там остановился - уже не помню.
Да, XSD этот проект тоже генерит. Но помнится не всё типы поддерживаются, т.к. я отлаживал только то, что мне было нужно.
Что ещё: нужно было бы избавиться от классов-контрактов типа *List. Они избыточны. Т.е. достаточно в аттрибуте укуазать, что это будет List такого-то типа.
Цитата:
Сообщение от
mazzy
было бы круто, если бы ты выложил проект на гитхаб или еще куда.
где можно будет твой проект форкнуть и предложить изменения.
С удовольствием передам тебе это право.