GWT RPC: DTO vs. DAO?

I've started learning GWT about a week ago and here's the question I can't answer for sure.

Here's the server-side:

// 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 { ... }

I need to somehow create a GWT widget to visualize Article. Passing Article won't work, since it's not serializable and moreover, it has some BL. So, there are 2 ways:

The first one is to use DTOs like:

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;
}

The I'll have to implement a repository logic in my GWT RPC service:

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

The sec开发者_Python百科ond way is to use DAOs:

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);
  }
  ...
}

I like the first one, because it's really stupid. I like the second one because it's quite intellectual. Which one should I choose to make the code easier to understand and maintain?

In projects I've worked on, people seem to differ a lot in their opinions about the best approach to take with problems like this. There are pros and cons for both. The DTO approach is now supported by GWT in an API called RequestFactory, and is advertised as an alternative to "standard" GWT RPC usage (your DAO approach). You gain performance and integration with GWT's data binding framework, and the cost of maintaining the DTOs. I think it's a good trade-off, but for small projects it might be overkill.

Typically DAOs are objects that determine data access methods of your system, while DTOs define data that is used by DAOs. So your first method is quite good but it is actually DAO/DTO method with MyRPCRepository being actually DAO (Data Access Object).

Second method is totally weird to my taste. It is some kind of service that allows you to access some pieces of your data and yet it retains some state (usually you want DAOs to be stateless).

So I vote for the first method, but repository should probably be called ArticleDAO and similar DAOs would be there for other data objects.

The question to ask is "how do you intend to use any of the solutions?" Assuming you have a kind of table UI on the client side, where you always show articelId, title and text (knowing that you are describing a kind of "Online Forum" I can assume you don't show the text, but lets pretend I did not know that). Now, with a DTO you simply can transfer a bunsh (one page?) of objects to the client. That means the transfer is done in one chunk and there is only one request from the client to fullfill. With your DAO approach (which I would not call DAO but "Service" in this case) you might still send a bunsh of objects in one request/response to the client, but a cascade of small requests to display title and text will come back from the client.

So the question to ask is: how does the user interact with your system? In your concrete example I always would transfer "id" and "title" and only use a second request/DAO approch for the text.

OTOH again, if only a few users are using the system (dozens or a few hundret) I would use the approach that is most easiest to develop or maintain.