Re: @CommitAfter for GenericDao
so this? FooFacade { @CommitAfter public void saveSomething(Something something) { doSaveSomething(something); } @CommitAfter public void saveAListOfSomethings(List 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(List 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(List 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 GenericDao { > > @CommitAfter > > public void save(T entity); > > } > > > > public abstract class GenericDaoImpl { > > @Override > > public void save(T entity) { > > entityManager.persist(entity); > &g
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 : > 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(List 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(List 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 GenericDao { >> > @CommitAfter >> > public void save(T entity); >> > } >> > >> > public abstract class GenericDaoImpl { >> > @Override >> > public void save(T entity) { >> > entityManager.persist(entity); >> > } >> > } >> > >> > public interface UserDao extends GenericDao { } >> > >> > public class UserDaoImpl extends GenericDaoImpl implements >> > UserDao { } >> > >> > and respective
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(List 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(List 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 GenericDao { > > @CommitAfter > > public void save(T entity); > > } > > > > public abstract class GenericDaoImpl { > > @Override > > public void save(T entity) { > > entityManager.persist(entity); > > } > > } > > > > public interface UserDao extends GenericDao { } > > > > public class UserDaoImpl extends GenericDaoImpl 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
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(List 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 GenericDao { > @CommitAfter > public void save(T entity); > } > > public abstract class GenericDaoImpl { > @Override > public void save(T entity) { > entityManager.persist(entity); > } > } > > public interface UserDao extends GenericDao { } > > public class UserDaoImpl extends GenericDaoImpl 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
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.
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(List 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 GenericDao { > @CommitAfter > public void save(T entity); > } > > public abstract class GenericDaoImpl { > @Override > public void save(T entity) { > entityManager.persist(entity); > } > } > > public interface UserDao extends GenericDao { } > > public class UserDaoImpl extends GenericDaoImpl 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.
@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 GenericDao { @CommitAfter public void save(T entity); } public abstract class GenericDaoImpl { @Override public void save(T entity) { entityManager.persist(entity); } } public interface UserDao extends GenericDao { } public class UserDaoImpl extends GenericDaoImpl 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