Argumenty przeciwko typowemu konwerterowi obiektów JSF ze statycznym atrybutem WeakHashMap

Question

Chcę uniknąć kodu płyty kotła w celu utworzenia listy elementów SelectItem, aby odwzorować moje jednostki/dtos między widokiem i modelem, więc użyłem tego snippet generycznego konwertera obiektów:

@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; 
} 

} 

Istnieje już wiele answers dla pytań similliar, ale chcę waniliowy roztwór (bez * twarzy). Poniższe punkty nadal pozostawiają mi pewności co do jakości moim fragmencie:

1. Gdyby to było takie proste, to dlaczego nie istnieje ogólny obiekt zbudować konwerter do JSF?
2. Dlaczego tak wielu ludzi wciąż używa numeru SelectItems? Czy nie ma większej elastyczności dzięki zastosowaniu podejścia generycznego? Na przykład. # {dto.label} można szybko zmienić na # {dto.otherLabel}.
3. Biorąc pod uwagę, że chodzi tylko o zmapowanie widoku i modelu, czy istnieje jakaś główna wada podejścia generycznego?

Answer 1

Takie podejście jest hackowate, a pamięć nieefektywna.

Jest "w porządku" w małej aplikacji, ale zdecydowanie nie w dużej aplikacji z dziesiątkami lub setkami tysięcy potencjalnych podmiotów, do których można się odwoływać w f:selectItems. Co więcej, tak duża aplikacja ma ogólnie pamięć cache drugiego poziomu. WeakHashMap staje się wówczas bezużyteczny i jest skuteczny tylko wtedy, gdy jednostka jest fizycznie usuwana z bazowego magazynu danych (a więc również z bufora jednostek drugiego poziomu).

Z pewnością jest to czynnik "zabawny", ale naprawdę nie polecam używania go w "ciężkiej produkcji".

Jeśli nie chcesz używać istniejącego rozwiązania z biblioteki narzędziowej, takiej jak OmniFaces SelectItemsConverter, jak już znalazłeś, która jest zasadniczo całkowicie bezpaństwowa i nie korzysta z żadnych połączeń DAO/usługi, najlepszym rozwiązaniem jest streszczenie wszystkich Twoje jednostki ze wspólnym bazowym interfejsem/klasą i zamiast tego podłączają do tego konwerter. To wciąż wymaga tylko połączenia DAO/usługi. Zostało to szczegółowo opisane w tym dokumencie:A: Implement converters for entities with Java Generics.