Смешивание Проверка JAR 303 и руководство (через Apache Commons) в объектах DDD

Question

Многие объекты домена в нашем домашнем проекте нуждаются в проверке поля, и для этой цели мы используем commons-lang. Например:

public class Position { 
    private static final int LATITUDE_AMPLITUDE = 90; 
    private static final int LONGITUDE_AMPLITUDE = 180; 

    private Float latitude; 
    private Float longitude; 

    public Position(float latitude, float longitude) { 
     Validate.inclusiveBetween(-LATITUDE_AMPLITUDE, LATITUDE_AMPLITUDE, latitude, 
       "Latitude must be +- " + LATITUDE_AMPLITUDE); 
     Validate.inclusiveBetween(-LONGITUDE_AMPLITUDE, LONGITUDE_AMPLITUDE, longitude, 
       "Longtitude must be +- " + LATITUDE_AMPLITUDE); 

     this.latitude = latitude; 
     this.longitude = longitude; 
    } 
} 

Мы решили не использовать JSR 303, потому что это домен пары объектов с инфраструктурой и требует внешнего вмешательства, что будет срабатывать проверки.

Но когда мы начали внедрять конечные точки REST, мы снова столкнулись с проблемой проверки, поскольку json-преобразователи не используют конструктор классов, а вводят значения через Reflection.

Очень легко проверить объекты через аннотацию JSR303 и Джерси @Valid, но для этого требуется аннотировать объекты домена с помощью JSR303. И у нас есть несколько вариантов:

1. Использовать только проверку JSR303. Имхо, это плохой вариант. Бизнес-уровень, который работает с этими объектами, также должен иметь проверенные объекты без сложного (более сложного, чем просто new) инициирования проверки JSR303.
2. Используйте JSR303 + ручную проверку. Он будет удовлетворять как: прикладным, так и бизнес-уровням, но делает объекты домена жирными из-за зависимости JSR303 и его аннотаций.

Что вы думаете об этом? Это хороший способ сочетания как JSR303, так и ручной проверки?

Answer 1

Проработав много с обеих моделей, я лично считаю, что проверка JB 303 bean более важна для работы. Под этим я подразумеваю чисто использование аннотаций проверки боба, без ручного кода проверки.

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

Большая часть моего опыта была с Hibernate Validator, что я нашел хорошей, быстрой реализацией JSR 303.