Есть ли доступный API для представления различных единиц товара, таких как KG, Liter, Meter, KM и т.д. - программирование
Подтвердить что ты не робот

Есть ли доступный API для представления различных единиц товара, таких как KG, Liter, Meter, KM и т.д.

В моем проекте где-то я должен работать с unitOfIssue от Items. Теперь различные предметы, конечно, могут иметь разные единицы представления. Итак, я искал какой-то API или каким-то образом, чтобы элегантно справиться с этой ситуацией.

Есть ли какой-либо доступный API, который предоставляет некоторый способ представления этих единиц? Я слышал о JScience, который кажется впечатляющим, но снова я столкнулся с другой проблемой с отображением его в JPA. После некоторой работы google я обнаружил, что в этом контексте происходит некоторая работа как JScience-JPA, но похоже, что это не но стабильный для использования в производстве.

Я также нашел что-то о JSR-275, но из эта страница JCP кажется, что она была отклонена.

Затем я наткнулся на unitsofmeasure, о котором я еще не разобрался. Но опять же возникает такая же проблема. Может ли это быть сопоставлено с JPA?

Изменить: - Из this SO question Я наткнулся на Java Numbers with Unit, но я не знаю, готова ли она к производству или нет.

Я действительно смущен, особенно после просмотра этих опций выше. И JPA вызывает дополнительную озабоченность в отношении того, могу ли я использовать любой из них или нет. Кто-нибудь когда-либо сталкивался с такой ситуацией и нашел выход из этого? Мне действительно нужна помощь здесь. Что я должен использовать? И если другого выхода нет, тогда будет подходящий способ представлять эти единицы. Один из способов, я вижу, используя enums. но, конечно, это будет последний выбор.

4b9b3361

ОТВЕТЫ

Ответ 1

Я был в проекте, в котором мы широко использовали JSR-275 (до того, как он был отклонен JCP). Первоначально мы не использовали JPA, но позже было решено, что мы должны сохранить нашу модель с использованием JPA 2.0, и мне пришлось иметь дело с сохранением объектов измерения.

Это не может быть ответом на ваш вопрос, но может привести некоторые интересные мысли к обсуждению.

Мы рассмотрели несколько альтернатив:

  • Меры были сериализуемыми, и JPA может отображать любой сериализуемый объект. Проблема здесь в том, что меры будут сохранены как двоичные объекты в базе данных, и они будут подвержены всем проблемам сериализации (например, версии и т.д.).
  • Мы могли бы адаптировать нашу модель, сохраняя данные в необработанных типах (т.е. целые числа, двойные и т.д.) при условии, что мы соглашаемся на использование международной единицы измерения для каждой единицы. Таким образом, поля будут основываться на типах, поддерживаемых JPA, но геттеры и сеттеры будут использовать объекты измерения. Настройте сопоставление JPA на основе полей, а не свойств. Проблема здесь заключалась в том, чтобы изменить модель для изменения инкапсулированных данных, не затрагивая открытый интерфейс объектов домена.
  • Поскольку мы использовали hibernate как наш поставщик персистентности, мы можем согласиться отклониться от стандарта JPA и использовать типы пользовательских значений hibernate для сопоставления мер объекты к соответствующим примитивным типам. Затем мы могли бы сопоставлять наши типы с помощью аннотаций спящего режима для этой цели. (См. пример здесь). Предостережение в этом заключается в том, что он утрачивает постоянство независимости поставщика.

В итоге мы использовали альтернативу №3, и это сработало для нас хорошо.