Additional thoughts below: "My approach has been to create DTOs for each case. I was now thinking of using the JPA relationships and lazy loading instead"
I would recommend to go the "lazy loading" route in this case. I think having a unique DTO will make things easier to maintain instead of creating specific DTOs for each case. If you are using GWT-RPC and you are in this case populating the DTO's yourself, you can check the user's "role" for example and based on that, lazy or eagerly fetch what you need. If you are using hibernate, this can be accomplished in a few different ways. Your default configurations are typically lazy there. In the UI, you will always receive the same DTO. There you should at that point either know the user's role or check based on the response you received. The fields that do not apply to the user based on role should then be null and you should check for that. On Thu, Apr 19, 2012 at 12:05 PM, Thomas Broyer <[email protected]> wrote: > > On Thursday, April 19, 2012 5:46:07 PM UTC+2, Thomas Lefort wrote: >> >> I want to avoid having to use DTOs for transferring my Users with RPC. >> Basically I have a number of rpc calls for my users, and based on the >> configuration and the user rights, etc... there is a number of fields I >> want to hide. My approach has been to create DTOs for each case. I was now >> thinking of using the JPA relationships and lazy loading instead. For >> instance I store additional information (bio, etc...) in an "Additional" >> object, with a onetoone relationship and lazy loading. So I guess based on >> the call I just need to load the field or not, instead of filling up a >> dedicated DTO each time I send a User with "holes". >> >> Does that make sense? any one has cons on this idea? will RPC send empty >> fields or will it be more clever and just not add the fields that are null? >> > > I don't know JPA very well, but I think lazy-loading will get in your way > here. What you need is to conditionally load the Additional object, and in > the case you don't, you want the field to be 'null'. AFAIK, this is pretty > easy with JPA. > That being said, maybe detaching your object from the session would be > enough to have a 'null' in the field, and more importantly have the getter > not throw any exception but return simply return the null; but that doesn't > really change the fact that you'd better ask JPA to load the Additional > object if you need it (so it could use a JOIN instead of 2 SELECTs for > instance) than use lazy-loading (and calling the getter as a trigger to > load the Additional object) > > -- > You received this message because you are subscribed to the Google Groups > "Google Web Toolkit" group. > To view this discussion on the web visit > https://groups.google.com/d/msg/google-web-toolkit/-/chqJD0S9QZMJ. > > To post to this group, send email to [email protected]. > To unsubscribe from this group, send email to > [email protected]. > For more options, visit this group at > http://groups.google.com/group/google-web-toolkit?hl=en. > -- Alfredo Quiroga-Villamil AOL/Yahoo/Gmail/MSN IM: lawwton -- You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.
