Ayende @ Rahien

Greg commented on Refactor This: Answers

Tue, 06 Apr 2010 12:50:41 GMT

Cross cutting concerns so, use AOP?

Corey commented on Refactor This: Answers

Mon, 05 Apr 2010 23:07:40 GMT

I'll probably toy with this idea on my own and if you're up for taking a look when it's "ready" to poke holes in. I may need some ideas for the Windsor magic to take it the long haul, but I should be able to prove the concept without it for now.

Corey commented on Refactor This: Answers

Mon, 05 Apr 2010 18:18:54 GMT

Even if you were to ignore my comments above. You could achieve the equivalent to what exists now in the RhinoQueueTransport (or at least before you changed things) with the below chain named for comparison. The only thing I see being lost is the logging with very specific messages in each of the catch blocks. Did I miss something? Policies .WrapBehaviorChainsWith() .WrapBehaviorChainsWith() .WrapBehaviorChainsWith() .WrapBehaviorChainsWith();

Bryan commented on Refactor This: Answers

Mon, 05 Apr 2010 17:11:09 GMT

I'm with Colin. Corey's refactoring is a major step in the right direction. If you want more, we need use cases, unit tests, something, anything more to put the original code into context.

Colin commented on Refactor This: Answers

Mon, 05 Apr 2010 16:45:29 GMT

Maybe it's not that people didn't read the code and more that there weren't any unit tests to verify behavior. ;) Also, I have a hunch that much of the complexity found in that method was the consequence of decisions made in other parts of the code. I agree that none of the posted refactorings felt quite right, but without more context it's hard to come up with a good solution.

Ayende Rahien commented on Refactor This: Answers

Mon, 05 Apr 2010 15:53:56 GMT

Corey, Error handling is not something that the IMessageModule author should care about. That is not something that they need to, because the infrastructure takes care of this.

Corey commented on Refactor This: Answers

Mon, 05 Apr 2010 15:51:25 GMT

The end user writing behaviors outside the core provided ones. In other words a person who might write a message module currently for whatever reason, providing an NHibernate session, auditing, authorization, etc. Ugh I forgot generics were stripped out of comments. I meant BaseBehavior

Ayende Rahien commented on Refactor This: Answers

Mon, 05 Apr 2010 15:42:54 GMT

Corey, What user? There isn't a user here, this is infrastructure code that the user never sees

Corey commented on Refactor This: Answers

Mon, 05 Apr 2010 15:35:13 GMT

As it currently exists an exception can be thrown by. 1. Processing message in consumer throws. 2. An error in MessageArrived, MessageCompleted, BeforeMessageCompleted, MessageProcessingFailure 3. Commiting the transaction. 4. Deserializing message The ways that exceptions are handled differently. 1. Transaction is rolled back with an error action for incrementing failure and message put back into queue. 2. Error is logged and ignored. I may be simplifying something in my head, but I'm pretty sure those can all be accounted for. I might even question the need of some of the events at all if this were the approach taken. Additionally the behaviors could be given the option on how to handle errors if they each need their own error handling. I don't think error handling awareness is all that much to ask of the end user if you're adding behaviors. You could also get rid of the generic catch all ErrorBehavior and provide something more explicit in the BaseBehavior