GWT RPC: DTO против DAO? - PullRequest
       24

GWT RPC: DTO против DAO?

3 голосов
/ 27 сентября 2011

Я начал изучать GWT около недели назад, и вот вопрос, на который я точно не могу ответить.

Вот серверная часть:

// business object - has logic
interface Article {
  String getTitle(); // lazy
  void setTitle();
  String getText(); // lazy
  void setText();
  Set<Comment> getComments(); // lazy
}

// also has logic
interface Comment { ... }

Мне нужно как-то создать виджет GWT для визуализации Article. Передача Article не будет работать, так как она не сериализуема и, кроме того, имеет некоторый BL. Итак, есть 2 способа:

Первый - использовать DTO, такие как:

class ArticleDTO implements Serializable {
  public int articleId;
  public String title;
  public String text;
}

class CommentDTO implements Serializable {
  public int commentId;
  public int articleId;
  public String commentText;
}

Мне нужно будет реализовать логику хранилища в моей службе RPC GWT:

class MyRPCRepository ... {
  ArticleDTO getArticle(int id);
  void saveArticle(ArticleDTO article);
  void deleteArticle(ArticleDTO article);
  ...similar things for comments here...
}

Второй способ заключается в использовании DAO:

class ArticleDAO implements Serializable {
  private transitional MyRPC rpc;
  private int articleId; // only this one is serializable

  public ArticleDAO(MyRPC rpc, int articleId) { ... }

  public String getTitle() {
    // i know it would require more code in real
    return rpc.getArticleTitle(articleId);
  }
  ...
}

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

Ответы [ 3 ]

3 голосов
/ 27 сентября 2011

В проектах, над которыми я работал, люди, похоже, сильно расходятся во мнениях о том, как лучше подходить к таким проблемам. Есть плюсы и минусы для обоих. Подход DTO теперь поддерживается GWT в API под названием RequestFactory и рекламируется как альтернатива «стандартному» использованию GWT RPC (ваш подход DAO). Вы получаете производительность и интеграцию с платформой привязки данных GWT, а также затраты на обслуживание DTO. Я думаю, что это хороший компромисс, но для небольших проектов это может быть излишним.

2 голосов
/ 27 сентября 2011

Обычно DAO - это объекты, которые определяют методы доступа к данным вашей системы, в то время как DTO определяют данные, которые используются DAO.Итак, ваш первый метод довольно хорош, но на самом деле это метод DAO / DTO, в котором MyRPCRepository фактически является DAO (объектом доступа к данным).

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

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

1 голос
/ 27 сентября 2011

Вопрос, который нужно задать: «Как вы собираетесь использовать какое-либо из решений?» Предполагая, что у вас есть своего рода пользовательский интерфейс таблицы на стороне клиента, где вы всегда показываете articelId, заголовок и текст (зная, что вы описываете своего рода «онлайн-форум», я могу предположить, что вы не показываете текст, но давайте представим, что я не знал что). Теперь с помощью DTO вы можете просто передать пакет (одну страницу?) Объектов клиенту. Это означает, что передача выполняется в одном чанке, и от клиента требуется только один запрос на полное заполнение. С вашим подходом DAO (который я бы назвал не DAO, а «Сервис» в этом случае), вы все равно могли бы отправить кучу объектов в одном запросе / ответе клиенту, но каскад небольших запросов для отображения заголовка и текста вернется от клиента.

Итак, вопрос, который нужно задать: как пользователь взаимодействует с вашей системой? В вашем конкретном примере я всегда передаю «id» и «title» и использую только второй запрос / DAO-подтверждение для текста.

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

...