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 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.comwrote:
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.comwrote:
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
EntityRepositoryPersonDto,
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.comwrote:
+1
just to complete this thread the main issue is not the
implementation
but
the exposed API:
public interface EntityRepositoryE, PK extends Serializable
would become
public interface EntityDtoRepositoryE, 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
