Как я могу разделить бизнес-логику между сервером и клиентом, если я использую RequestFactory?

Question

Допустим, у меня есть бин Employee, у которого есть свойство dateOfBirth:

public class Employee {
    ...
    private Date dateOfBirth;
    ... 
    public Date getDateOfBirth() {...}
    public void setDateOfBirth(Date date) {...}
    ...
}

Чтобы использовать RequestFactory, я создаю EmployeeProxy:

@ProxyFor (value = Employee.class)
public inteface EmployeeProxy extends EntityProxy {
    ... 
    Date getDateOfBirth();
    void setDateOfBirth(Date date);
    ...
}

Теперь предположим, что у меня есть статический метод, который дает Employee, он возвращает его возраст:

public class Util {
    public static int getAge(Employee e) {
        return (new Date()).getYear()-e.getDateOfBirth().getYear();
    }
}

Если бы я не использовал RequestFactory и также имел класс Employee на клиенте, я мог бы разделить "Util" между сервером и клиентом и вызвать getAge() для экземпляров Employee на клиенте. Так как я использую RequestFactory, я полагаю, что мне нужно создать новую версию Util для клиента, например:

public class Util {
    public static int getAge(EmployeeProxy e) {
        return (new Date()).getYear()-e.getDateOfBirth().getYear();
    }
}

Что может быть хорошим решением для создания версии Util как для клиента, так и для сервера?

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

Answer 1

В качестве лучшей практики - Ваш класс Employee должен реализовывать интерфейс EmployeeProxy.

Разве это не решит вашу проблему использования класса Util на стороне сервера тоже.