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

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

Предположим, имеет ли 'Пользовательский' объект 'loginid' как ограничение на уникальность данных, был бы это быть мудрым проверить, существует ли пользовательская запись уже с этим, вошел в систему имя перед созданием или модификацией.

ИЛИ

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

Примечание: В настоящее время никакие такие проверки не осуществляются на коде генерала шва.

Мы в настоящее время используем Шов 2.2, Richfaces с В спящем режиме.

15
задан Joe 30 January 2010 в 11:32
поделиться

3 ответа

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

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

Так что я бы сделал обоих. Предполагая, что вы продлеваете от Entityhome SWAL:

  1. в методе сохранения () Запустите запрос, чтобы убедиться, что в системе уникальна. Если это не добавьте сообщение об ошибке к соответствующему управлению и возврату NULL.
  2. Оберните вызов в Super.Persist () и поймайте ограничения Super.Persistexception, отображение общего дубликата сообщения об ошибке

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

Как упомянутое Ширвину, создавая валидатор JSF, является отличной идеей (замена) # 1 выше, но вы ДОЛЖЕН ОЖИДАТЬ ХАРАКТЕРИВНЫЕ И ПОЛУЧИТЬ ОБРАЩЕНИЕВИСАЦИОНАЦИОНАЦИЙСКИЕМЕЦИИ.

7
ответ дан 1 December 2019 в 04:27
поделиться

Вызывается button.addActionListener (this) , поскольку этот реализует интерфейс ActionListener . При нажатии кнопки вызывается метод actionPerformed (ActionEvent e) (определяется интерфейсом и реализуется классом).

-121--3286677-

Метод ActionListener является механизмом обратного вызова. Всякий раз, когда элемент управления добавляется для запуска ActionEvent , вызывается метод public void actionPerformed (ActionEvent e) .

Я не понимаю, где вызывается actionPerformed. Я вижу, что он определен в классе, но нет места, где этот метод вызывается.

Это вызывается внутренними механизмами компонента пользовательского интерфейса. Концептуально, вы можете думать о код выглядит немного так:

public class Button {
  private final List<ActionListener> listeners = new ArrayList<ActionListener>();

  public void addActionListener(ActionListener l) {
    listeners.add(l);
  }

  public void click() {
    ActionEvent event = new ActionEvent(this, 0, "click");
    for (ActionListener l : listeners) {
      l.actionPerformed(event);
    }
  }
}
-121--3286675-

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

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

2
ответ дан 1 December 2019 в 04:27
поделиться

Я не согласен с обработкой 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
ответ дан 1 December 2019 в 04:27
поделиться
Другие вопросы по тегам:

Похожие вопросы: