Cause in REST you can push your entities to your REST endpoints then simply convert it to DTO, that's a stateless case which work but not that general.
*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 John D. Ament <john.d.am...@gmail.com> > 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 > <rmannibu...@gmail.com>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 <thomas....@gmail.com> > > > > > 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 > > > <rmannibu...@gmail.com>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 <thomas....@gmail.com> > > > > > > > > > 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 > > > > > <rmannibu...@gmail.com>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 <jeano...@gmail.com> > > > > > > > > > > > > > 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 <thomas....@gmail.com> > > > > > > > > > > > > > > > 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 < > > > > > john.d.am...@gmail.com > > > > > > > > >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 > > > > > > > > > > > > > > > > > > > > > > > > > > > >
