Re: @CommitAfter for GenericDao
so this?
FooFacade {
@CommitAfter
public void saveSomething(Something something) {
doSaveSomething(something);
}
@CommitAfter
public void saveAListOfSomethings(ListSomething somethings) {
for (Something something : somethings) { doSaveSomething(something); }
}
private void doSaveSomething(Something something) {
// add a bunch of validations
// and maybe a bunch of business rules
// and then updates to other objects
// and then finally
dao.save(something);
// oh and maybe some post processing
}
}
You just add 3 lines of code and retain SoC.
- Original Message -
From: Tony Nelson
To: Tapestry users
Sent: Monday, May 05, 2014 6:43 PM
Subject: RE: @CommitAfter for GenericDao
The problem we ran into was explicitly what I documented in my original
e-mail. In our Spring based implementation all of our @Transactional
annotations we in our logic layer, and it worked well. I started out using
@CommitAfter exactly the same way, until I ran into methods like:
public void saveSomething(Something something) {
// add a bunch of validations
// and maybe a bunch of business rules
// and then updates to other objects
// and then finally
dao.save(something);
// oh and maybe some post processing
}
public void saveAListOfSomethings(ListSomething somethings) {
for (Something something : somethings) { saveSomething(something); }
}
After running into this too many times in our codebase, we made the decision
to remove all @CommitAfter annotation from our logic layer (even wrote a test
case) and push them out to where the actual transaction logically existed. For
us this includes web pages, REST endpoints, and even command line programs.
This has worked very well for us.
I'm also not sure I completely agree with your separation of concerns
argument either. Granted, I would never allow anyone to @Inject Session into a
page class, that definitely belongs in the DAO layer, but a simple annotation
the demarks a transaction doesn't feel out of place to me in a page class.
-Original Message-
From: John [mailto:j...@quivinco.com]
Sent: Monday, May 05, 2014 1:10 PM
To: Tapestry users
Subject: Re: @CommitAfter for GenericDao
At the risk of sounding like a fanatic...
I would avoid using @CommitAfter or anything similar to do with
persistence in page classes, it contravenes the OO seperation of
concerns principle. (For the same reasons @CommitAfter should also not
be in interface definitions as suggested in the Tapestry docs' because
it's implementation specific.)
A better place would be a facade layer* between your DAOs and your page
classes. This might not be justified if you want to keep your
application architecture minimal, but even so it represents best
practice and is a great place to code your business logic. Your page
classes can then focus exclusively on delivery of page content and your
DAOs on pure data access.
regards,
John
*http://en.wikipedia.org/wiki/Facade_pattern
- Original Message -
From: Tony Nelson
To: Tapestry users
Sent: Wednesday, April 30, 2014 9:59 PM
Subject: RE: @CommitAfter for GenericDao
From my experience, you really don't want to put CommitAfter on a
generic method like that.
It really doesn't do what you expect in code like this:
void saveSomeData(ListWidget widgets) {
for (Widget w: widgets) {
widgetDao.saveWidget(widget);
}
}
In that case, assuming saveWidget is annotated with @CommitAfter,
every iteration of the loop will commit separately, which is likely not
what you want.
The @CommitAfter annotation is much better used in your page classes
to commit transactions after a logical unit of work is complete.
Tony
-Original Message-
From: Eugen [mailto:eugens...@gmail.com]
Sent: Wednesday, April 30, 2014 4:48 PM
To: Tapestry users
Subject: @CommitAfter for GenericDao
Hi,
I try to use the CommitAfter on a GenericDao, but the method does
not
commit the transaction. Does it exists a worcaround to do that?
This is the code:
public interface GenericDaoT {
@CommitAfter
public void save(T entity);
}
public abstract class GenericDaoImplT {
@Override
public void save(T entity) {
entityManager.persist(entity);
}
}
public interface UserDao extends GenericDaoUser { }
public class UserDaoImpl extends GenericDaoImplUser implements
UserDao { }
and respective advisor in AppModule:
@Match(*Dao)
public static void adviseTransactions(JpaTransactionAdvisor
advisor,
MethodAdviceReceiver receiver) {
advisor.addTransactionCommitAdvice(receiver
Re: @CommitAfter for GenericDao
Thanks to all for detailed explanations,
The facade pattern looks good for me ;-)
I'll change my architecture to met it...
beste regards
Eugen
2014-05-05 19:43 GMT+02:00 Tony Nelson tnel...@starpoint.com:
The problem we ran into was explicitly what I documented in my original
e-mail. In our Spring based implementation all of our @Transactional
annotations we in our logic layer, and it worked well. I started out using
@CommitAfter exactly the same way, until I ran into methods like:
public void saveSomething(Something something) {
// add a bunch of validations
// and maybe a bunch of business rules
// and then updates to other objects
// and then finally
dao.save(something);
// oh and maybe some post processing
}
public void saveAListOfSomethings(ListSomething somethings) {
for (Something something : somethings) { saveSomething(something); }
}
After running into this too many times in our codebase, we made the decision
to remove all @CommitAfter annotation from our logic layer (even wrote a test
case) and push them out to where the actual transaction logically existed.
For us this includes web pages, REST endpoints, and even command line
programs. This has worked very well for us.
I'm also not sure I completely agree with your separation of concerns
argument either. Granted, I would never allow anyone to @Inject Session into
a page class, that definitely belongs in the DAO layer, but a simple
annotation the demarks a transaction doesn't feel out of place to me in a
page class.
-Original Message-
From: John [mailto:j...@quivinco.com]
Sent: Monday, May 05, 2014 1:10 PM
To: Tapestry users
Subject: Re: @CommitAfter for GenericDao
At the risk of sounding like a fanatic...
I would avoid using @CommitAfter or anything similar to do with
persistence in page classes, it contravenes the OO seperation of
concerns principle. (For the same reasons @CommitAfter should also not
be in interface definitions as suggested in the Tapestry docs' because
it's implementation specific.)
A better place would be a facade layer* between your DAOs and your page
classes. This might not be justified if you want to keep your
application architecture minimal, but even so it represents best
practice and is a great place to code your business logic. Your page
classes can then focus exclusively on delivery of page content and your
DAOs on pure data access.
regards,
John
*http://en.wikipedia.org/wiki/Facade_pattern
- Original Message -
From: Tony Nelson
To: Tapestry users
Sent: Wednesday, April 30, 2014 9:59 PM
Subject: RE: @CommitAfter for GenericDao
From my experience, you really don't want to put CommitAfter on a
generic method like that.
It really doesn't do what you expect in code like this:
void saveSomeData(ListWidget widgets) {
for (Widget w: widgets) {
widgetDao.saveWidget(widget);
}
}
In that case, assuming saveWidget is annotated with @CommitAfter,
every iteration of the loop will commit separately, which is likely not
what you want.
The @CommitAfter annotation is much better used in your page classes
to commit transactions after a logical unit of work is complete.
Tony
-Original Message-
From: Eugen [mailto:eugens...@gmail.com]
Sent: Wednesday, April 30, 2014 4:48 PM
To: Tapestry users
Subject: @CommitAfter for GenericDao
Hi,
I try to use the CommitAfter on a GenericDao, but the method does
not
commit the transaction. Does it exists a worcaround to do that?
This is the code:
public interface GenericDaoT {
@CommitAfter
public void save(T entity);
}
public abstract class GenericDaoImplT {
@Override
public void save(T entity) {
entityManager.persist(entity);
}
}
public interface UserDao extends GenericDaoUser { }
public class UserDaoImpl extends GenericDaoImplUser implements
UserDao { }
and respective advisor in AppModule:
@Match(*Dao)
public static void adviseTransactions(JpaTransactionAdvisor
advisor,
MethodAdviceReceiver receiver) {
advisor.addTransactionCommitAdvice(receiver);
}
if I place the save() function into the UserDao all works fine.
Thanks in advice
Eugen
---
--
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
Since 1982, Starpoint Solutions has been a trusted source of human
capital and solutions. We are committed to our clients, employees,
environment, community and social concerns. We foster an inclusive
culture based on trust, respect, honesty and solid performance. Learn
more about Starpoint and our social responsibility at
http://www.starpoint.com/social_responsibility
Re: @CommitAfter for GenericDao
At the risk of sounding like a fanatic...
I would avoid using @CommitAfter or anything similar to do with persistence in
page classes, it contravenes the OO seperation of concerns principle. (For
the same reasons @CommitAfter should also not be in interface definitions as
suggested in the Tapestry docs' because it's implementation specific.)
A better place would be a facade layer* between your DAOs and your page
classes. This might not be justified if you want to keep your application
architecture minimal, but even so it represents best practice and is a great
place to code your business logic. Your page classes can then focus exclusively
on delivery of page content and your DAOs on pure data access.
regards,
John
*http://en.wikipedia.org/wiki/Facade_pattern
- Original Message -
From: Tony Nelson
To: Tapestry users
Sent: Wednesday, April 30, 2014 9:59 PM
Subject: RE: @CommitAfter for GenericDao
From my experience, you really don't want to put CommitAfter on a generic
method like that.
It really doesn't do what you expect in code like this:
void saveSomeData(ListWidget widgets) {
for (Widget w: widgets) {
widgetDao.saveWidget(widget);
}
}
In that case, assuming saveWidget is annotated with @CommitAfter, every
iteration of the loop will commit separately, which is likely not what you want.
The @CommitAfter annotation is much better used in your page classes to
commit transactions after a logical unit of work is complete.
Tony
-Original Message-
From: Eugen [mailto:eugens...@gmail.com]
Sent: Wednesday, April 30, 2014 4:48 PM
To: Tapestry users
Subject: @CommitAfter for GenericDao
Hi,
I try to use the CommitAfter on a GenericDao, but the method does not
commit the transaction. Does it exists a worcaround to do that?
This is the code:
public interface GenericDaoT {
@CommitAfter
public void save(T entity);
}
public abstract class GenericDaoImplT {
@Override
public void save(T entity) {
entityManager.persist(entity);
}
}
public interface UserDao extends GenericDaoUser { }
public class UserDaoImpl extends GenericDaoImplUser implements
UserDao { }
and respective advisor in AppModule:
@Match(*Dao)
public static void adviseTransactions(JpaTransactionAdvisor advisor,
MethodAdviceReceiver receiver) {
advisor.addTransactionCommitAdvice(receiver);
}
if I place the save() function into the UserDao all works fine.
Thanks in advice
Eugen
-
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
Since 1982, Starpoint Solutions has been a trusted source of human capital
and solutions. We are committed to our clients, employees, environment,
community and social concerns. We foster an inclusive culture based on trust,
respect, honesty and solid performance. Learn more about Starpoint and our
social responsibility at http://www.starpoint.com/social_responsibility
This email message from Starpoint Solutions LLC is for the sole use of the
intended recipient(s) and may contain confidential and privileged information.
Any unauthorized review, use, disclosure or distribution is prohibited. If
you are not the intended recipient, please contact the sender by reply email
and destroy all copies of the original message. Opinions, conclusions and
other information in this message that do not relate to the official business
of Starpoint Solutions shall be understood as neither given nor endorsed by it.
--
T ususcib, -mil uer-usus...@tpetr.aace.rg
Fr ddtina cmmnd, -mil uer-hlptaesryapch.og
---
This email is free from viruses and malware because avast! Antivirus protection
is active.
http://www.avast.com
RE: @CommitAfter for GenericDao
The problem we ran into was explicitly what I documented in my original e-mail.
In our Spring based implementation all of our @Transactional annotations we
in our logic layer, and it worked well. I started out using @CommitAfter
exactly the same way, until I ran into methods like:
public void saveSomething(Something something) {
// add a bunch of validations
// and maybe a bunch of business rules
// and then updates to other objects
// and then finally
dao.save(something);
// oh and maybe some post processing
}
public void saveAListOfSomethings(ListSomething somethings) {
for (Something something : somethings) { saveSomething(something); }
}
After running into this too many times in our codebase, we made the decision to
remove all @CommitAfter annotation from our logic layer (even wrote a test
case) and push them out to where the actual transaction logically existed. For
us this includes web pages, REST endpoints, and even command line programs.
This has worked very well for us.
I'm also not sure I completely agree with your separation of concerns argument
either. Granted, I would never allow anyone to @Inject Session into a page
class, that definitely belongs in the DAO layer, but a simple annotation the
demarks a transaction doesn't feel out of place to me in a page class.
-Original Message-
From: John [mailto:j...@quivinco.com]
Sent: Monday, May 05, 2014 1:10 PM
To: Tapestry users
Subject: Re: @CommitAfter for GenericDao
At the risk of sounding like a fanatic...
I would avoid using @CommitAfter or anything similar to do with
persistence in page classes, it contravenes the OO seperation of
concerns principle. (For the same reasons @CommitAfter should also not
be in interface definitions as suggested in the Tapestry docs' because
it's implementation specific.)
A better place would be a facade layer* between your DAOs and your page
classes. This might not be justified if you want to keep your
application architecture minimal, but even so it represents best
practice and is a great place to code your business logic. Your page
classes can then focus exclusively on delivery of page content and your
DAOs on pure data access.
regards,
John
*http://en.wikipedia.org/wiki/Facade_pattern
- Original Message -
From: Tony Nelson
To: Tapestry users
Sent: Wednesday, April 30, 2014 9:59 PM
Subject: RE: @CommitAfter for GenericDao
From my experience, you really don't want to put CommitAfter on a
generic method like that.
It really doesn't do what you expect in code like this:
void saveSomeData(ListWidget widgets) {
for (Widget w: widgets) {
widgetDao.saveWidget(widget);
}
}
In that case, assuming saveWidget is annotated with @CommitAfter,
every iteration of the loop will commit separately, which is likely not
what you want.
The @CommitAfter annotation is much better used in your page classes
to commit transactions after a logical unit of work is complete.
Tony
-Original Message-
From: Eugen [mailto:eugens...@gmail.com]
Sent: Wednesday, April 30, 2014 4:48 PM
To: Tapestry users
Subject: @CommitAfter for GenericDao
Hi,
I try to use the CommitAfter on a GenericDao, but the method does
not
commit the transaction. Does it exists a worcaround to do that?
This is the code:
public interface GenericDaoT {
@CommitAfter
public void save(T entity);
}
public abstract class GenericDaoImplT {
@Override
public void save(T entity) {
entityManager.persist(entity);
}
}
public interface UserDao extends GenericDaoUser { }
public class UserDaoImpl extends GenericDaoImplUser implements
UserDao { }
and respective advisor in AppModule:
@Match(*Dao)
public static void adviseTransactions(JpaTransactionAdvisor
advisor,
MethodAdviceReceiver receiver) {
advisor.addTransactionCommitAdvice(receiver);
}
if I place the save() function into the UserDao all works fine.
Thanks in advice
Eugen
---
--
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
Since 1982, Starpoint Solutions has been a trusted source of human
capital and solutions. We are committed to our clients, employees,
environment, community and social concerns. We foster an inclusive
culture based on trust, respect, honesty and solid performance. Learn
more about Starpoint and our social responsibility at
http://www.starpoint.com/social_responsibility
This email message from Starpoint Solutions LLC is for the sole use
of the intended recipient(s) and may contain confidential and
privileged information. Any unauthorized review, use, disclosure or
distribution is prohibited
RE: @CommitAfter for GenericDao
For the record, I agree with what Tony has said. It's usually better to @CommitAfter on a page action or on a service rather than a low level DAO. That being said, I think your problem is annotating the interface instead of the concrete class. Prior to recent 5.4 builds, annotations were not copied from interface to service. Thiago has fixed this recently and if you upgrade to 5.4 beta you can annotate the interface.
@CommitAfter for GenericDao
Hi,
I try to use the CommitAfter on a GenericDao, but the method does not
commit the transaction. Does it exists a worcaround to do that?
This is the code:
public interface GenericDaoT {
@CommitAfter
public void save(T entity);
}
public abstract class GenericDaoImplT {
@Override
public void save(T entity) {
entityManager.persist(entity);
}
}
public interface UserDao extends GenericDaoUser {
}
public class UserDaoImpl extends GenericDaoImplUser implements UserDao {
}
and respective advisor in AppModule:
@Match(*Dao)
public static void adviseTransactions(JpaTransactionAdvisor advisor,
MethodAdviceReceiver receiver) {
advisor.addTransactionCommitAdvice(receiver);
}
if I place the save() function into the UserDao all works fine.
Thanks in advice
Eugen
-
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
RE: @CommitAfter for GenericDao
From my experience, you really don't want to put CommitAfter on a generic
method like that.
It really doesn't do what you expect in code like this:
void saveSomeData(ListWidget widgets) {
for (Widget w: widgets) {
widgetDao.saveWidget(widget);
}
}
In that case, assuming saveWidget is annotated with @CommitAfter, every
iteration of the loop will commit separately, which is likely not what you want.
The @CommitAfter annotation is much better used in your page classes to commit
transactions after a logical unit of work is complete.
Tony
-Original Message-
From: Eugen [mailto:eugens...@gmail.com]
Sent: Wednesday, April 30, 2014 4:48 PM
To: Tapestry users
Subject: @CommitAfter for GenericDao
Hi,
I try to use the CommitAfter on a GenericDao, but the method does not
commit the transaction. Does it exists a worcaround to do that?
This is the code:
public interface GenericDaoT {
@CommitAfter
public void save(T entity);
}
public abstract class GenericDaoImplT {
@Override
public void save(T entity) {
entityManager.persist(entity);
}
}
public interface UserDao extends GenericDaoUser { }
public class UserDaoImpl extends GenericDaoImplUser implements
UserDao { }
and respective advisor in AppModule:
@Match(*Dao)
public static void adviseTransactions(JpaTransactionAdvisor advisor,
MethodAdviceReceiver receiver) {
advisor.addTransactionCommitAdvice(receiver);
}
if I place the save() function into the UserDao all works fine.
Thanks in advice
Eugen
-
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
Since 1982, Starpoint Solutions has been a trusted source of human capital and
solutions. We are committed to our clients, employees, environment, community
and social concerns. We foster an inclusive culture based on trust, respect,
honesty and solid performance. Learn more about Starpoint and our social
responsibility at http://www.starpoint.com/social_responsibility
This email message from Starpoint Solutions LLC is for the sole use of the
intended recipient(s) and may contain confidential and privileged information.
Any unauthorized review, use, disclosure or distribution is prohibited. If
you are not the intended recipient, please contact the sender by reply email
and destroy all copies of the original message. Opinions, conclusions and
other information in this message that do not relate to the official business
of Starpoint Solutions shall be understood as neither given nor endorsed by it.
