Scenario:
An event is raised in class A that needs to be handled by a method in class B. (currently via a delegate)
The data that gets passed from the event to the method is currently wrapped in class C.
This obviously requires class B to be dependent on class C.
Is there any techniques/refactoring that i can perform in order to remove this dependecy?
e.g. unrolling the data back to simple primitive data types and passing them directly.
You could serialize to XML, and than read the XML directly via XPATH (without deserializing)
unrolling to primitives would work, but be certain that you really do want to remove this dependency. It is perfectly valid for classes A and B to both depend on C if C is a bridge between them, or if C feeds both of them, etc.
unrolling to primitives removes a compilation dependency, but not a data dependency, and may actually be "denormalizing" the design by removing an entity (class C) which is logicially required
I agree with Steven Lowe; The dependency probably is valid. The only alternative I can offer is to depend on an interface instead of an actual class, but it pretty much boils down to the same thing.
As most others have said, the dependency on C is probably valid.
However, if depending on C gives you problems, it might be because C is too complicated or has too many dependencies on its own.
If class C is passed in an event, it should probably be a POCO class with no dependencies of its own, so you might want to consider refactoring that.
If C has complicated methods of its own, it is a good bet that they actually belong on class A.
Have you looked at Dependency Injection frameworks like Structuremap to at least centralize these dependencies and make them configurable? I haven't tried it with events/delegate types, but it's a great tool if you're passing a lot of custom types/interfaces around your layers.