Ps: you can make a cdi bean an ejb from cdi extension Le 12 juil. 2013 08:12, "Romain Manni-Bucau" <rmannibu...@gmail.com> a écrit :
> 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" <han...@yahoo.com.cn> 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 <john.d.am...@gmail.com >> >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 >> >> <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 >> >>>>>>>> >> >>
