ATG JavaBean поверх RepositoryItem

Я не понимаю, как использовать repositoryItem в ATG. Как мне нужно построить индивидуальную логику на нем.

Нужно ли создавать обычный JavaBean поверх repositoryItem или мне нужно использовать его как есть? Я постараюсь объяснить:

  1. Логика на репозиторий Элемент:

    RepositoryItem store = getRepository().getItem(..);
String address = store.getPropertyValue(..);

  2. Логика на JavaBean:

    class StoreBean {
  String address;

  StoreBean(RepositoryItem store) {
    address = store.getPropertyValue(..);
 }
}

Тогда я могу использовать StoreBean так, как я хочу, чтобы получить его поля (ленивая загрузка для них, например).

Каковы будут лучшие практики в ATG?

Источник

2 ответа

Решение

Это вопрос предпочтений.

Что вы не получаете с RepositoryItem Объекты - это строгая проверка типов. Вы должны либо сделать предположения о типе RepositoryItem вы работаете с или вы должны делать ручные проверки в вашем коде (см. пример ниже). Кроме того, так как RepositoryItem свойства хранятся в виде метаданных, вы должны знать 1) фактические имена свойств из дескриптора репозитория XML и 2) вам нужно знать типы, для которых требуется приведение типов (пример: String firstName = (String) item.getProperty("firstName");) Вот пример проверки для обеспечения RepositoryItem объект имеет тип "sku":

RepositoryItemDescriptor skuItemDescriptor = getCatalogTools().getCatalog().getItemDescriptor(getCatalogTools().getBaseSKUItemType());
if (!RepositoryUtils.isTypeOfItemDesc(itemDescriptor, skuItemDescriptor)) {
    throw new IllegalArgumentException("RepositoryItem must be of type " + getCatalogTools().getBaseSKUItemType());
}

Если вы решите не использовать JavaBeans, вы увеличите риск ошибок времени выполнения в своем приложении. Мое предложение заключается в том, что у вас есть здоровый баланс между использованием объектов RepistoryItem и объектов-оболочек. Для критически важных элементов, которые вы планируете использовать в большом объеме базы кода, я предлагаю использовать объект-оболочку.

Я полагаю, что если вы создаете объекты-оболочки, то для согласованности вы следуете тому же шаблону проектирования, который использует Oracle Commerce. Например, элемент "заказ" обернут OrderImpl и реализует ChangedProperties интерфейс.

public class OrderImpl
extends CommerceIdentifierImpl
implements Order, ChangedProperties

http://docs.oracle.com/cd/E52191_03/Platform.11-1/apidoc/atg/commerce/order/OrderImpl.html

Источник

Стандартные реализации репозитория ATG по большей части не используют JavaBeans. Одним из больших недостатков использования JavaBeans и их отложенной загрузки в память будет потеря многих функций кэширования репозитория и увеличение объема используемой памяти. Например, вы не сможете отслеживать статистику кеша или периодически делать недействительной кеш. Вы также будете иметь накладные расходы на создание экземпляров, когда у вас будет огромный набор результатов repotiroyitem из запроса.

Вместо этого вы также можете использовать DynamicBean, который позволяет ссылаться на свойства репозитория, аналогичные Java-бинам, например Profile.city.

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

Источник
Другие вопросы по тегам