CODEWITHSUNDEEP
javaoracle-databasee-commercejavabeansatg
a.chugunov
a.chugunov

Reputation: 174

ATG JavaBean over RepositoryItem

I doesn't understand how to use repositoryItem in ATG. How do I need construct customized logic on it.

Do I need to create usual JavaBean over repositoryItem or I need to use it as is? I will try to explain:

  1. Logic on repositoryItem:

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

  2. Logic on JavaBean:

    class StoreBean {
  String address;

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

Then I can use StoreBean how I want, to get it fields(lazy load for them, for example).

What will be best practices in ATG?

Upvotes: 1

Views: 469

Answers (2)

Shailendra
Shailendra

Reputation: 11

ATG out of box repository implementations do not use JavaBeans for the most part. One big disadvantage of using JavaBeans and lazy loading them into memory will be to lose many repository caching features and will increase your memory footprint. For instance you will not be able to monitor your cache statistic or invalidate cache periodically. You will also have overheads of instantiations when you have huge repotiroyitem result set from a query.

Instead you can also use DynamicBean which lets you refer to repository properties similar to java beans for instance Profile.city.

If you only want to wrap them so that developers don't accidentally parse them incorrectly, you can write a util class per repository for various types of ready write operations and centralize your type safety.

Upvotes: 1

Matt Sidesinger
Matt Sidesinger

Reputation: 2144

It is a matter of preference.

What you do not get with RepositoryItem objects is strong type checking. You must either make assumptions about the type of RepositoryItem you are working with or you have to do manual checks in your code (see example below). Additionally, since the RepositoryItem properties are stored as a metadata, you have to know 1) the actual names of the properties from the XML repository descriptor and 2) you need to know the types, which requires type casting (Example: String firstName = (String) item.getProperty("firstName");) Here is an example of a validation to ensure the RepositoryItem object is of type "sku":

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

If you take the approach of not using "JavaBeans", then you are increasing the risk of having runtime errors in your application. My suggestion is that you have a healthy balance between using RepistoryItem objects and wrapper objects. For critical items you plan to use in a large amount of your code base, I suggest using a wrapper object.

I suggest that if you create wrapper objects, that for consistency, you follow the same design pattern that Oracle Commerce uses. For example, the "order" item is wrapped by OrderImpl and implements the ChangedProperties interface.

public class OrderImpl
extends CommerceIdentifierImpl
implements Order, ChangedProperties

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

Upvotes: 3

Related Questions