Совместное использование кода в движке приложения GWT

Question

У меня есть класс Employee

 @PersistenceCapable(identityType = IdentityType.APPLICATION)
    public class Employee {
        @PrimaryKey
        @Persistent(valueStrategy = IdGeneratorStrategy.IDENTITY)
        private Key key;

        @Persistent
        private String firstName;

        @Persistent
        private String lastName;

        @Persistent
        private Date hireDate;

        public Employee(String firstName, String lastName, Date hireDate) {
            this.firstName = firstName;
            this.lastName = lastName;
            this.hireDate = hireDate;
        }

        // Accessors for the fields.  JDO doesn't use these, but your application does.

        public Key getKey() {
            return key;
        }

        public String getFirstName() {
            return firstName;
        } 
        public void setFirstName(String firstName) {
            this.firstName = firstName;
        } 

        public String getLastName() {
            return lastName;
        } 
        public void setLastName(String lastName) {
            this.lastName = lastName;
        } 

        public Date getHireDate() {
            return hireDate;
        } 
        public void setHireDate(Date hireDate) {
            this.hireDate = hireDate;
        } 
    }

Я использовал JDO для движка приложения. Теперь я хочу поделиться этим кодом между сервером и клиентом. В каком пакете я должен хранить это. На самом деле я пробовал оба пути. Ни один не сработал. Пожалуйста, поделитесь, если вы уже сделали этот тип кодов.

Answer 1

Если то, что вы ищете, это создание ваших сущностей как на клиенте, так и на сервере, то помещение классов в пакет "client" сделает свое дело.

Но если вы пытаетесь передать свои постоянные сущности через RPC, это, вероятно, не сработает из коробки. DataNucleus «включает» байт-код, и RPC не может затем сериализоваться. Hibernate имеет похожую проблему, пожалуйста, посмотрите эту статью , она очень хорошо объясняет проблему и предлагает альтернативы.

Я создаю DTO для решения этой проблемы. Это немного больше работы, но это действительно зависит от того, сколько у вас есть сущностей.

Answer 2

Вот почему я использую API низкого уровня. Я написал вспомогательный класс, который преобразует сущность в pojo и обратно. Таким образом, я получаю сущность, которая преобразуется в желаемый POJO, который затем отправляется клиенту. От клиента тот же POJO возвращается к серверу, который преобразуется в сущность с помощью моего вспомогательного класса, а затем простой вызов put делает свое дело. Вам не нужно ничего прикреплять / прикреплять ... Я могу поделиться кодом, если хотите.

Answer 3

Нам, вероятно, нужно больше деталей, так как вы можете столкнуться с рядом проблем, но вот несколько советов:

• Пакет не так важен, пока оба GWTКомпилятор и Javac могут видеть это.Я храню общий код в пакете с соответствующим названием ... «общий».:)

• Ключ недоступен в GWT, поэтому используйте кодированную строку Ключ .

• JDO сложно,но работоспособный.Более новые версии GWT (после выпуска Java AppEngine) смогли обработать расширение JDO в DataNucleus.Я бы удостоверился, что вы работаете вне транка или недавнего снимка, на случай, если DataNucleus - ваша проблема.

• Убедитесь, что вы отсоединили свои объекты перед отправкой их клиенту.*

Answer 4

Я делал это раньше, но только в небольшом тестовом приложении. Предполагая, что вы используете GWT-RPC, он должен работать довольно гладко. Вам придется сделать две вещи:

1. Поместите код в пространство имен «клиента», то есть в каталог, который компилируется GWT. Вы все еще можете использовать этот код на сервере.
2. Нажмите компиляцию и начните исправлять ошибки. Главное, что вы найдете, это то, что тип «Ключ» недоступен на земле GWT. Вместо этого вы можете использовать строковый ключ. См. Раздел «ключ как закодированная строка» в соответствующей документации .

Если вы не используете GWT-RPC, вы сами по себе. JSON привлекателен для этой цели, но требует значительных усилий. Это должно быть лучше в GWT 2.0, но не исчезнет полностью.