Your requirement is based on your experience, i do not think a must in REST application.
Some case we can wrap the result in query result like this. select new UserResult(name, email ) from User u to get a ValueObject directly. Hantsy On 7/12/2013 14:12, Romain Manni-Bucau wrote: > Hi > > Depending the case DTO are not an option. > > I agree in rest app i wouldnt it but if not possible (maybe through another > Bean) it would kill this module for half of the usages i see since i'd need > to add this layer. > Le 12 juil. 2013 06:55, "hantsy" <[email protected]> a écrit : > >> No DTO please, data module for data access, why we care about DTO. >> >> A question about the data, the difference for EJB and none EJB environment. >> >> if possible in a EJB envoriment, proxy the Repository and add @Stateless >> and transaction declaration to Repository automatically at runtime. >> >> Regards >> >> Hantsy >> On 7/10/2013 23:23, Thomas Hug wrote: >>> I wouldn't label the feature with DTO but rather as some general result >>> transformation - might also be useful for e.g. native queries. Going back >>> to the API suggestion, from that perspective such an annotation should >>> probably also work on method level, so I'd keep the forEntity out there. >>> >>> >>> On Wed, Jul 10, 2013 at 4:22 PM, John D. Ament <[email protected] >>> wrote: >>> >>>> Personally, I don't like this idea. >>>> >>>> A DAO should do DAO stuff. >>>> A DTO should do DTO stuff. >>>> >>>> The transformation of your entities into some other POJO shouldn't be >>>> inside your DAO. >>>> >>>> Right now, I use google guava to do DTO work on entities going back and >>>> forth over a REST API. Works well IMHO. >>>> >>>> John >>>> >>>> >>>> On Wed, Jul 10, 2013 at 9:21 AM, Romain Manni-Bucau >>>> <[email protected]>wrote: >>>> >>>>> globally my answer meant "if forEntity is sometimes mandatory, >> sometimes >>>>> not this is maybe not the right place" >>>>> >>>>> i thought to add it to mapper config >>>>> >>>>> *Romain Manni-Bucau* >>>>> *Twitter: @rmannibucau <https://twitter.com/rmannibucau>* >>>>> *Blog: **http://rmannibucau.wordpress.com/*< >>>>> http://rmannibucau.wordpress.com/> >>>>> *LinkedIn: **http://fr.linkedin.com/in/rmannibucau* >>>>> *Github: https://github.com/rmannibucau* >>>>> >>>>> >>>>> >>>>> 2013/7/10 Thomas Hug <[email protected]> >>>>> >>>>>> Making forEntity non-optional would then be redundant for the regular >>>>> cases >>>>>> using the base interface, so I wouldn't. But I see that it should be >>>>>> clearly documented then as things might get confusing... >>>>>> >>>>>> >>>>>> On Wed, Jul 10, 2013 at 3:02 PM, Romain Manni-Bucau >>>>>> <[email protected]>wrote: >>>>>> >>>>>>> do you mean you force forEntity = Person.class? >>>>>>> >>>>>>> looks ok for me since the only constraint is to add the dto types >>>>>> somewhere >>>>>>> :) >>>>>>> >>>>>>> *Romain Manni-Bucau* >>>>>>> *Twitter: @rmannibucau <https://twitter.com/rmannibucau>* >>>>>>> *Blog: **http://rmannibucau.wordpress.com/*< >>>>>>> http://rmannibucau.wordpress.com/> >>>>>>> *LinkedIn: **http://fr.linkedin.com/in/rmannibucau* >>>>>>> *Github: https://github.com/rmannibucau* >>>>>>> >>>>>>> >>>>>>> >>>>>>> 2013/7/10 Thomas Hug <[email protected]> >>>>>>> >>>>>>>> Hmm and I assumed DTOs are dead and buried :-) >>>>>>>> >>>>>>>> Packing this in the base interface feels kind of clunky to me - >>>> also >>>>>>>> considering that there are repositories without the need to extend >>>>> the >>>>>>> base >>>>>>>> interface. What about something like >>>>>>>> >>>>>>>> @Repository(forEntity = Person.class) >>>>>>>> @ResultMapper(entityMapper = MapperX.class, keyMapper = >>>>> MapperY.class) >>>>>>>> public interface PersonRepository extends >>>> EntityRepository<PersonDto, >>>>>>>> DtoPk> { ... } >>>>>>>> >>>>>>>> Having the Entity on @Repository takes precedence and the type >>>>>> parameters >>>>>>>> are in this case just for convenience. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On Wed, Jul 10, 2013 at 2:35 PM, Romain Manni-Bucau >>>>>>>> <[email protected]>wrote: >>>>>>>> >>>>>>>>> +1 >>>>>>>>> >>>>>>>>> just to complete this thread the main issue is not the >>>>> implementation >>>>>>> but >>>>>>>>> the exposed API: >>>>>>>>> >>>>>>>>> public interface EntityRepository<E, PK extends Serializable> >>>>>>>>> >>>>>>>>> would become >>>>>>>>> >>>>>>>>> public interface EntityDtoRepository<E, PK extends Serializable, >>>>> Dto, >>>>>>>>> DtoPk> >>>>>>>>> >>>>>>>>> *Romain Manni-Bucau* >>>>>>>>> *Twitter: @rmannibucau <https://twitter.com/rmannibucau>* >>>>>>>>> *Blog: **http://rmannibucau.wordpress.com/*< >>>>>>>>> http://rmannibucau.wordpress.com/> >>>>>>>>> *LinkedIn: **http://fr.linkedin.com/in/rmannibucau* >>>>>>>>> *Github: https://github.com/rmannibucau* >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> 2013/7/10 Jean-Louis MONTEIRO <[email protected]> >>>>>>>>> >>>>>>>>>> Hello guys, >>>>>>>>>> >>>>>>>>>> Just used DS Data module yesturday, and I was wondering if we >>>>> could >>>>>>>> add a >>>>>>>>>> feature allowing on-the-fly conversion to DTO. >>>>>>>>>> For example, we could use modelmapper (or similar to convert >>>> DAO >>>>>>> return >>>>>>>>>> values to DTO objects). >>>>>>>>>> >>>>>>>>>> Adding a mapper interface to delegate to would also allow >>>> people >>>>> to >>>>>>>> plug >>>>>>>>>> their own implementation in. >>>>>>>>>> >>>>>>>>>> WDYT? >>>>>>>>>> >>>>>>>>>> JLouis >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> 2013/7/1 Thomas Hug <[email protected]> >>>>>>>>>> >>>>>>>>>>> Hi John >>>>>>>>>>> Thnx for the message, missed that one. Looks like there's a >>>>>> default >>>>>>>>>> profile >>>>>>>>>>> needed (test-persistence.xml only part of the specific server >>>>>>>>> profiles). >>>>>>>>>>> Will check tonight. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On Mon, Jul 1, 2013 at 2:42 AM, John D. Ament < >>>>>>>> [email protected] >>>>>>>>>>>> wrote: >>>>>>>>>>>> Hi >>>>>>>>>>>> >>>>>>>>>>>> Whoever brought in the data module, can you double check >>>> your >>>>>>> tests >>>>>>>>> and >>>>>>>>>>>> license headers? >>>>>>>>>>>> >>>>>>>>>>>> I think it's just your tests, but it's failing during a rat >>>>>> check >>>>>>>>>>>> >> https://builds.apache.org/job/DeltaSpike%20RAT-Check/org.apache.deltaspike.modules$deltaspike-data-module-impl/558/testReport/org.apache.deltaspike.data.impl/QueryResultTest/org_apache_deltaspike_data_impl_QueryResultTest/ >>>>>>>>>>>> John >>>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> -- >>>>>>>>>> Jean-Louis >>>>>>>>>> >>
