> Perhaps a good analogy is Site Server Commerce 3.0 and its use of the "pipeline" (I don't recall if this was in prior versions or not... > it's been a while). The "pipeline" had a non-hierarchical arrangement of components that implemented the > IPipelineComponent interface (I think that was the name). The message (a name-value object, if I remember correctly) > would be passed into the pipeline and each component in the chain had the opportunity to annotate the message in their > own way. The components were decoupled from one another and they were not hierarchical; being hierarchical implies a > coupling as the child has to be aware of the parent and vice versa. The CoR decouples any knowledge of parent from > child or predecessor to successor by coordinating the passing of messages between them. > Right?
I've not used Site Server, but what you are describing doesn't sound like a traditional CoR implementation to me.. In the CoR pattern, you create a chain of objects to examine a request and each object decides whether to pass it on to the next object or process it. In effect, each node "knows" about the next node (at least as an interface) and decides whether the request will continue down the chain. In looking at the interface definition for IPipelineComponent, it has processing support but there is no linkage to connect a chain together or to continue the processing down the chain. Maybe I misread it, but it looks like something above the IPipelineComponent is acting as a list owner and knows about each registered component which is what the CoR avoids. I completely agree that CoR is very useful. I think the CoR pattern has great merit when you want to give more than one object a chance to process a request. If you are mapping to only a single processing object then it might be overkill. Best Regards, Mark Smith =================================== This list is hosted by DevelopMentor� http://www.develop.com View archives and manage your subscription(s) at http://discuss.develop.com
