проверяет нарушение ограничений перед сохранением объекта

каков наилучший механизм предотвращения проверок нарушения ограничений перед созданием / модификацией объекта?

предположим, что если сущность "пользователь" имеет "loginid" в качестве уникального ограничения, было бы разумно проверить, есть ли запись Пользователя с этим именем loginid перед созданием или изменением.

или

вы бы позволили базе данных бросить ConstraintViolationException и обработать это сообщение соответствующим образом на уровне пользовательского интерфейса. Где должны ли такие проверки применяться в рамках шва jboss.

Примечание: В настоящее время такие проверки не применяются к коду seam-gen.

в настоящее время мы используем шов 2.2, Richfaces с Hibernate.

11
hibernate jpa richfaces seam

3 ответов

даже если вы проверяете условие в своем коде перед сохранением объекта пользователя, всегда есть шанс, что кто-то создаст дубликат loginid между временем проверки и сохранением нового пользователя.

однако будет проще отобразить соответствующее сообщение об ошибке в пользовательском интерфейсе, если вы сделаете явную проверку. Если у вас есть несколько противопоказаний в таблице, улавливание ConstraintViolationException не позволит вам легко определить, какое ограничение было нарушаться.

поэтому я бы сделал и то, и другое. Предполагая, что вы расширяетесь от EntityHome шва:

  1. в методе persist () выполните запрос, чтобы убедиться, что loginid уникален. Если он не добавляет сообщение об ошибке в соответствующий элемент управления и возвращает null.
  2. оберните вызов super.persist () и поймать ConstraintViolationException, отображая общее повторяющееся сообщение об ошибке

редактировать

Как Шервин Яловень упомянутое создание валидатора JSF-отличная идея (замена) #1 выше, но вы все равно должны ожидать худшего и поймать ConstraintViolationException.

6

Я не согласен с обработкой ConstraintException. Я написал валидатор, который проверяет дубликаты перед сохранением, и он отлично работает.

вот пример проверки дубликатов писем.

@Name("emailValidator")
@Validator
@BypassInterceptors
@Transactional
public class UniqueEmailValidator implements javax.faces.validator.Validator, Serializable {

private static final long serialVersionUID = 6086372792387091314L;

@SuppressWarnings("unchecked")
public void validate(FacesContext facesContext, UIComponent component, Object value) throws ValidatorException {
    EntityManager entityManager = (EntityManager) Component.getInstance("entityManager");
    String newEmail = (String) value;
    String oldEmail = String.valueOf(component.getAttributes().get("oldEmail"));
    if (oldEmail != null && !oldEmail.equalsIgnoreCase(newEmail)) {
        List<User> users = entityManager.createQuery(
                "SELECT DISTINCT u FROM " + User.class.getName() + " p where lower(p.fromEmail) = :email").setParameter("email",
                newEmail.toLowerCase()).getResultList();
        if (!users.isEmpty()) {
            Map<String, String> messages = Messages.instance();
            throw new ValidatorException(new FacesMessage(FacesMessage.SEVERITY_ERROR, messages.get("admin.emailexists"), messages
                    .get("admin.emailexists")));
        }
    }
}
}

и в вашей форме (xhtml) вы пишете:

<s:decorate template="/layout/definition.xhtml">
        <ui:define name="label">#{messages['processdata.email']}</ui:define>
        <h:inputText id="fromEmail" size="30" required="true" value="#  {userAdmin.existingUser.fromEmail}">
            <f:validator validatorId="emailValidator"/>
            <f:attribute name="oldEmail" value="#{userAdmin.existingUser.fromEmail}" />
            <s:validate />
        </h:inputText>
    </s:decorate>

таким образом, он всегда будет проверять поля перед сохранением. Вы даже можете поместить тег a: support для проверки при изменении фокуса.

6

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

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

2