2

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 second 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?

Andrey Agibalov
  • 7,487
  • 7
  • 64
  • 110
  • 1
    I know this not your question therefore posting as comment. DTO's are anti pattern and GWT RPC is very basic(I know this will upset many but truth is bitter). You need to use GWT either with a restful backend or make use of dispatcher framwork like gwt_pltform http://code.google.com/p/gwt-platform/ – Shahzeb Sep 27 '11 at 06:27
  • @Shahzeb, if you think DTOs are an antipattern some references or reasons would be fine. Or do you only mean in regards to GWT? – Angel O'Sphere Sep 27 '11 at 11:49
  • @AngelO'Sphere http://www.jroller.com/raghukodali/entry/dto_an_antipattern_in_ejb and http://stackoverflow.com/questions/1440952/why-are-data-transfer-objects-an-anti-pattern – Shahzeb Sep 28 '11 at 00:31
  • 1
    @Shahzeb, sorry but the jroller article is not well written and not conclusiv. Everyone is using DTOs to transfer "display" information from the business tier to the "display and manipulation" tier, especially if it is going over the web. It is a prime principle in design of large systems that you convert external data at the sysem bounderies into your internal data. The "external" data are DTOs. That means when my data is created in a browser, for my system that browser is external. The data I receive, DTOs, get transformed into BOs (EJBs, POJOs, what ever). – Angel O'Sphere Sep 28 '11 at 12:30
  • 1
    The exact same is to be done if you transfer internal data to an external system. You translate it into DTOs suitable for the external sysem and you strip all internal data like primary keys etc. Doing something different is simply plain wrong and in the long run will lead to desaster. BTW: did you bother to read the answers to your own SO question? The conclusion there is the same ;D – Angel O'Sphere Sep 28 '11 at 12:32
  • @AngelO'Sphere we might get kicked out from here for this discussion :) but before that happens I will say this , I agree with you 100% you are totaly right as in today's date I am writing DTO's myself and I agree there is a scope for that especially if you are using Web service. But in that case that DTO replaces Domain model because those DTOs in that case are infect not the traditional DTO layer that used to tranfer data from Domain objects to presentation tier but THE domain model itself now . Early morning here hope I am making sense. Yes there is a room for them but – Shahzeb Sep 28 '11 at 22:53
  • should not be relied upon as a crtitical infrasture of in other words when you are working on project you assume the you will have a few tiers at different levels but DTO should not be assumed to be part of the core but if need arises then yes it does.As far as this question goes I think should try to avoid. – Shahzeb Sep 28 '11 at 22:56
  • If however you are using DTO so that you can strip off primary keys etc then thats the exact antipattern I am talking about.What are you achieving by doing this nothing. You could instead have a detached entity and send that over the wire. Which Question of mine are you referring to :) – Shahzeb Sep 29 '11 at 00:49
  • Sometimes what you achieve by doing this is creating an object that GWT can serialize. GWT doesn't always like serializing detached entities. Also, I don't always want to send the entire entity to every client. For example, if I am writing a poker game, I don't want to just send the detached entity for each player, including their cards. I only want to send the cards that are visible to the client making the request. – Peter Recore Sep 29 '11 at 18:48

3 Answers3

4

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.

Daniel
  • 9,414
  • 3
  • 41
  • 61
2

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.

Alex Gitelman
  • 23,471
  • 7
  • 49
  • 48
2

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.

Angel O'Sphere
  • 2,427
  • 16
  • 16