Reputation: 572
I'm adopting Castle Windsor for my WCF project and feel really amazed about this. However, I'm having a scenario that I don't really know if Castle Windsor supports. For example I have the following chained Interceptors
Interceptor 1 > Interceptor 2 > Interceptor 3 > Interceptor 4 > Real method
Interceptor 1 returns some data and I want that to be available in Interceptor 2 Interceptor 2 in turn does it work and returns the data that I want to make avaialbe in the 3,4, interceptor. The real case scenario is that we're having a WCF service, Interceptor 1 will parse the request header into a Header object(username, password, etc.). The latter interceptors and real method will ultilize this Header object. I know that I can use Session variable to transport data, but is it a built-in, more elegant, more reliable way to handle this?
Upvotes: 0
Views: 427
Reputation: 5801
What you are proposing:
These are both bad things.
Conceptually interceptors are a nice implementation of the decorator pattern. Put another way an interceptor can modify behavior, but should do so in a way that is transparent to the layers below it. Interceptors should not change the public interface or dependencies of what is being called. An interceptor can depend on the final method, but the final method should not depend on the interceptor.
If calling the method requires a header object, I would create an explicit WCF behavior (probably an IDispatchMessageInspector) to fill the requirement.
Then all the interceptors and the final method can assume that the header object is there because creating it is part of the public interface (for example by putting the behavior on the method implementation using an attribute).
The funny part is that the implementation of the message inspector behavior is essentially the same as an interceptor. The difference is that making your method dependent on an explicit behavior is clear. Making the method dependent on an implicit interceptor is not.
Upvotes: 2
Reputation: 172835
I don't think there is any built-in way to do this, and although you can use the Session, I would rather define an abstraction for this. You can inject the same instance of that abstraction in all interceptors that need to communicate.
Upvotes: 1