BlazeDS не обрабатывает внутренний класс Java DTO - PullRequest
Новая
       28

BlazeDS не обрабатывает внутренний класс Java DTO

1 голос
/ 19 августа 2011

Я заметил, что в BlazeDS есть определенные вещи, которые он не поддерживает, и часто бывает трудно это выяснить.Пример: полиморфизма нет.Нужно создавать методы с разными именами, так как методы с одинаковыми именами с разными параметрами создают конфликт.

Я пытаюсь выяснить, не поддерживает ли BlazeDS статические и нестатические внутренние классы Java. Подробности примера, указывающего на проблему: 

public class UserDTO {
     private  String name;
     private AddressDTO adddress;
     private PhoneDTO phone;
     ....

     public static class PhoneDTO {
          private String phoneNumber;
          .....
     }

     public class AddressDTO {
          private String address;
          .....
     }

Этот код работает нормально для передачи данных во Flex через BlazeDS, но приводит к ошибкам при передаче данных из Flex через BlazeDS обратно в Java.

@Service
@RemotingDestination(channels = { "my-amf" }, value = "UserService")
public class UserService {
   ....
   public UserDTO getUser(Long userID) {
      .....
      return userDTO;
   }

   public void updateUser(UserDTO userDTO) {
     ....
   }

   public void updatePhone(PhoneDTO phoneDTO) {
      .....
   }

Приведенный выше пример кода скомпилируется и будет работать метод getUser .С другой стороны, вызов методов updateUser или updatePhone приводит к ошибке BlazeDS.Есть ли особый способ использования внутренних классов во Flex или внутренние классы не поддерживаются?

Вот пример полученных сообщений об ошибках: 

[BlazeDS]Cannot create class of type 'com.test.dto.UserDTO.PhoneDTO'.
flex.messaging.MessageException: Cannot create class of type 'com.test.dto.UserDTO.PhoneDTO'. Type 'com.test.dto.UserDTO.PhoneDTO' not found.

Пример кода Flex: 

var thisPhone:PhoneDTO = new PhoneDTO();
thisPhone.phoneNumber = "8885551212";
updateTagsResult.token = userService.updatePhone(thisPhone);

Ответы [ 2 ]

2 голосов
/ 22 августа 2011

Что касается статических классов, я также очень скептически отношусь к их использованию. Статические классы возможны в Actionscript, но только в одном и том же файле (private static), и я не верю, что AMF3 это поддерживает.

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

1 голос
/ 24 августа 2011

Внутренние классы

Нет, отправка объекта Actionscript с псевдонимом во внутренний класс Java (статический или другой) не поддерживается "из коробки".

Как вы уже виделипри десериализации пакета AMF имя класса интерпретируется как внешний класс, а не как внутренний класс.

Однако вы можете реализовать это самостоятельно, если ваши классы реализуют IExternalizable ,( См. Здесь для получения дополнительной информации )

Альтернативой IExternalizable является использование подхода , подобного этому , который обеспечивает поддержку отправляемых Java Enum.через Flex.Они используют настраиваемую конечную точку десериализатора.

В интересах полноты следует отметить, что сериализация внутренних классов Actionscript поддерживается , однако метатег [RemoteClass] - нет.Вместо этого внутренние классы должны быть явно зарегистрированы с использованием registerClassAlias, обычно внутри статического метода внешнего класса.

Полиморфизм

Чтобы исправить точку в исходном сообщении:

.... Пример: полиморфизма нет.Нужно создавать методы с разными именами, так как методы с одинаковыми именами с разными параметрами создают конфликт.

Учитывая, что BlazeDS является продуктом на стороне сервера, я предполагаю, что вы имеете в видуспособ, которым BlazeDS обрабатывает полиморфизм и перегрузку в Java.В этом случае ваше утверждение неверно.

Например, допустим следующий код: 

@RemotingDestination
public class EchoService {
public String echo(String source)
{
    return "Received String";
}
public Object echo(Object source)
{
    return "Recieved object of type " + source.getClass().getName();
}

Выполнено следующим образом: 

remoteObject.echo("Hello") // result from service is "Received String"
remoteObject.echo(new Date()) // result from service is "Received object of type java.util.Date"

Однако этокак пример вашего вопроса, это не пример полиморфизма.Это перегрузка метода, которая отличается.

Полиморфизм поддерживается , как показано здесь: 

// Java
// This method on EchoService
public String echo(Employee employee)
{
    return employee.sayHello();
}

public class Employee {

    public String sayHello() {
        return "Hello, I'm an employee";
    }

}   
public class Manager extends Employee {

    @Override
    public String sayHello() {
        return "Hello, I'm a Manager";
    }
}

Выполняется следующим образом: 

// In flex...
remoteObject.echo(new Employee()) // Recieves "Hello, I'm an employee"
remoteObject.echo(new Manager()) // Recieves "Hello, I'm a Manager"

Если мы удалим метод echo(Employee employee), то результат будет: 

// In flex...
remoteObject.echo(new Employee()) // Recieves "Recieved object of type Employee"
remoteObject.echo(new Manager()) // Recieves "Recieved object of type Manager"
...