Плохо ли использовать карту JSF #view.attributes вместо #viewScope для хранения данных приложения с областью видимости?

В версиях JSF до 2.0 сохранять объекты в представлении можно было только с помощью UIViewRoot.set/getAttribute.

Однако в JSF 2.0 была введена отдельная область представления, которую можно использовать в EL через #{viewScope} или программно с помощью UIViewRoow.getViewMap(). Рекомендуется использовать область представления. Он реализован с использованием карты, которая хранится в UIViewRoot и сериализуется так же, как атрибуты представления в новом состоянии представления, поэтому она имеет тот же срок службы, что и атрибуты представления.

ОБНОВЛЕНИЕ

По словам Леонардо Урибе из команды MyFaces:

В JSF 2.2 было решено всегда хранить bean-компоненты области просмотра в сеансе (взгляните на описание аннотации @ViewScoped в javadoc). Но вы можете просто вызвать FaceContext.getViewRoot() и использовать карту атрибутов. Просто помните, что значения должны быть Serializable или реализовывать StateHolder.

Таким образом, похоже, что переносимым способом является использование карты атрибутов в UIViewRoot.

рекомендуется использовать viewScope. избегайте использования атрибутов корня представления (компонента в целом) по двум причинам:

1. теоретически существует вероятность того, что вы перезапишете атрибут корневого компонента представления. на практике это невозможно, поскольку ключи атрибутов реализуются с помощью enum (по крайней мере, в мохарре)

2. UIComponentBase.getAttributes возвращает конкретную реализацию Map: AttributesMap. эта реализация сначала проверяет, существует ли в компоненте метод с тем же именем, что и ключ карты. а если нет, то проверяет внутреннюю карту. если снова не найдено, проверяет карту компонента ValueExpression. так что это вообще неэффективно и, в особом случае, может привести к бесконечной рекурсии.

взгляните на AttributesMap.get, например:

public Object get(Object keyObj) {
    String key = (String) keyObj;
    Object result = null;
    if (key == null) {
        throw new NullPointerException();
    }
    if (ATTRIBUTES_THAT_ARE_SET_KEY.equals(key)) {
        result = component.getStateHelper().get(UIComponent.PropertyKeysPrivate.attributesThatAreSet);
    }
    Map<String,Object> attributes = (Map<String,Object>)
          component.getStateHelper().get(PropertyKeys.attributes);
    if (null == result) {
        PropertyDescriptor pd =
                getPropertyDescriptor(key);
        if (pd != null) {
            try {
                Method readMethod = pd.getReadMethod();
                if (readMethod != null) {
                    result = (readMethod.invoke(component,
                            EMPTY_OBJECT_ARRAY));
                } else {
                    throw new IllegalArgumentException(key);
                }
            } catch (IllegalAccessException e) {
                throw new FacesException(e);
            } catch (InvocationTargetException e) {
                throw new FacesException(e.getTargetException());
            }
        } else if (attributes != null) {
            if (attributes.containsKey(key)) {
                result = attributes.get(key);
            }
        }
    }
    if (null == result) {
        ValueExpression ve = component.getValueExpression(key);
        if (ve != null) {
            try {
                result = ve.getValue(component.getFacesContext().getELContext());
            } catch (ELException e) {
                throw new FacesException(e);
            }
        }
    }

    return result;
}

Думая о своем реквизите, это не имеет большого смысла, по крайней мере, с точки зрения веб-приложения. Состояние просмотра запоминает состояния компонентов: значения модели компонентов, которые изменены по сравнению с начальным состоянием и должны быть обработаны далее. если эти значения не нужно обрабатывать, то и запоминать долго не надо. мы можем думать о них как о «временных». и наоборот, если их нужно обрабатывать и запоминать в течение длительного времени, настойчивость — это путь. действительно, я не могу придумать ни одного случая, чтобы такого рода данные сохранялись дольше, чем сеанс, и короче, чем навсегда (постоянство).

Можете ли вы привести пример из реальной жизни?

лучший пример, который приходит мне на ум, — запомнить активный индекс для tabView или аккордеона, но это значение можно (и нужно) сохранять, если оно важно.

однако у каждой проблемы есть решение, первое, что я могу подумать, это то, что вы можете реализовать пользовательскую область, которая хранит эти значения в области приложения, используя определенное значение файла cookie (клиента) в качестве ключа.