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