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(List<Something> 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<Widget> 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<T> {
>> > @CommitAfter
>> > public void save(T entity);
>> > }
>> >
>> > public abstract class GenericDaoImpl<T> {
>> > @Override
>> > public void save(T entity) {
>> > entityManager.persist(entity);
>> > }
>> > }
>> >
>> > public interface UserDao extends GenericDao<User> { }
>> >
>> > public class UserDaoImpl extends GenericDaoImpl<User> 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
>
> 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.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
