针对具有静态WeakHashMap的通用JSF对象转换器的争论 [英] Arguments against a generic JSF object converter with a static WeakHashMap

问题描述

我想避免创建用于在视图和模型之间映射我的实体/dto的SelectItem列表的样板代码，因此我使用了此

I want to avoid boiler plate code for creating a list of SelectItems to map my entities/dtos between view and model, so I used this snippet of a generic object converter:

@FacesConverter(value = "objectConverter")
public class ObjectConverter implements Converter {

private static Map<Object, String> entities = new WeakHashMap<Object, String>();

@Override
public String getAsString(FacesContext context, UIComponent component, Object entity) {
    synchronized (entities) {
        if (!entities.containsKey(entity)) {
            String uuid = UUID.randomUUID().toString();
            entities.put(entity, uuid);
            return uuid;
        } else {
            return entities.get(entity);
        }
    }
}

@Override
public Object getAsObject(FacesContext context, UIComponent component, String uuid) {
    for (Entry<Object, String> entry : entities.entrySet()) {
        if (entry.getValue().equals(uuid)) {
            return entry.getKey();
        }
    }
    return null;
}

}

对于类似的问题已经有很多答案，但是我想要一个有效的解决方案(没有*面孔).以下几点仍使我不确定代码段的质量:

There are already many answers to similliar questions, but I want a vanilla solution (without *faces). The following points still leave me uncertain about the quality of my snippet:

1. 如果那样简单，为什么没有在 JSF ?
2. 为什么还有这么多人还在使用 SelectItems ?使用通用方法是否没有更大的灵活性?例如. #{dto.label}可以快速更改为#{dto.otherLabel}.
3. 鉴于范围仅是在视图和模型之间进行映射，那么通用方法是否有主要缺点?

1. If it was that easy, why isn't there a generic object converter build into JSF?
2. Why are so many people still using SelectItems? Isn't there more flexibility by using the generic approach? E.g. #{dto.label} can be quickly changed into #{dto.otherLabel}.
3. Given the scope is just to map between view and model, is there any major downside of the generic approach?

推荐答案

这种方法容易受到攻击，并且内存效率低下.

This approach is hacky and memory inefficient.

在小型应用程序中这是可以的"，但绝对不能在具有成千上万个潜在实体的大型应用程序中使用，而f:selectItems中可能会引用该实体.而且，这样的大型应用程序通常具有二级实体缓存. WeakHashMap然后变得无用，并且仅当实体从基础数据存储区(因此也从二级实体缓存)中物理移除时才有效.

It's "okay" in a small application, but definitely not in a large application with tens or hundreds of thousands of potential entities around which could be referenced in a f:selectItems. Moreover, such a large application has generally a second level entity cache. The WeakHashMap becomes then useless and is only effective when an entity is physically removed from the underlying datastore (and thus also from second level entity cache).

它肯定有一个有趣"的因素，但是我真的不建议在大量生产"中使用它.

It has certainly a "fun" factor, but I'd really not recommend using it in "heavy production".

如果您不想使用 OmniFaces SelectItemsConverter ，您已经发现它基本上是完全无状态的，并且不使用任何DAO/Service调用，那么最好的选择是使用通用的基本接口/类对所有实体进行抽象，然后将转换器挂接到该接口/类上.这仍然仅需要DAO/服务调用.在本问答中已对此进行了详细说明:针对具有以下内容的实体的实现转换器Java泛型.

这篇关于针对具有静态WeakHashMap的通用JSF对象转换器的争论的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！