Callback interface contract

Question

I have two .NET parties who needs be bound by a contract. Now, party1 and party2 need to be able call some methods on each other (most of it is calls and reporting result back). I have duplex contract in mind, but the parties are not using WCF.

Is there a design pattern for this?

Edit

The parties are part of the same application. I create the application (party1) and someone else creates a dll (party2) that I load dynamically. Now, both of us should be able to call methods on each other. So, I am out to create an interface contract between us. The intent is to know whether there is a know pattern to do that?

If they're not using WCF, how are they communicating? This is the kind of thing that's usually handled by a service stack that supports sessions. — millimoose, Jan 24 '13 at 12:52
Are the parts just coding different parts of a single application, calling directly each-other's assemblies? If so, interfaces (or abstract classes) + code contracts (see http://msdn.microsoft.com/en-us/library/dd264808.aspx) may be a good way to go — Lorenzo Dematté, Jan 24 '13 at 12:55
Also, a "classic" design pattern may be using dependency injection (http://martinfowler.com/articles/injection.html). But really, without more information and context, it is hard to tell... — Lorenzo Dematté, Jan 24 '13 at 12:58
The parties are part of the same application. I create the application (party1) and someone else creates a dll (party2) that I load dynamically. Now, both of us should be able to call methods on each other. So, I am out to create an interface contract between us. The intent is to know whether there is a know pattern to do that? — ajeshjohn, Jan 25 '13 at 05:10
Since they both are in the same AppDomain, you could use a regular pub/sub pattern, check my answer on [this question](http://stackoverflow.com/questions/14395442/implementing-a-message-subscription-mechanism-in-c-sharp/14395579#14395579). — khellang, Jan 25 '13 at 09:48

jgauffin · Accepted Answer · 2013-01-25T09:14:16.627

A common solution is to use some kind of pub/sub pattern. By doing so you can avoid circular dependencies.

Basically you create some kind of class which are used to subscribe on events (and publish them).

So both your classes does something like this (but with different events):

public class ClassA : IEventHandler<UserCreated>
{
    IEventManager _eventManager

    public ClassA(IEventManager manager)
    {
       // I subscribe on this event (which is published by the other class)
       manager.Subscribe<UserCreated>(this);
       _eventManager = manager;
    } 

    public void Handle(UserCreated theEvent)
    {
        //gets invoked when the event is published by the other class
    }

    private void SomeInternalMethod()
    {
        //some business logic

        //and I publish this event
        _eventManager.Publish(new EmailSent(someFields));
    }
}

The event manager (simplified and not thread safe):

public class EventManager
{
    List<Subscriber> _subscribers = new List<Subscriber>();

    public void Subscribe<T>(IEventHandler<T> subscriber)
    {
        _subscribers.Add(new Subscriber{ EventType = typeof(T), Subscriber = subscriber});
    }

    public void Publish<T>(T theEvent)
    {
        foreach (var wrapper in subscribers.Where(x => x == typeof(theEvent)))
        {
            ((IEventHandler<T>)wrapper.Subscriber).Handle(theEvent);
        }
    }
}

The small wrapper:

public class Subscriber
{
    public Type EventType;
    public object Subscriber;
}

Voila. the two classes are now loosely coupled from each other (while still being able to communicate with each other)

If you use an inversion of control container it get's easier since you can simplify the event manager and just use the container (service location) to resolve all subscribers:

public class EventManager
{
    IYourContainer _container;

    public EventManager(IYourContainer container)
    {
        _container = container;
    }

    public void Publish<T>(T theEvent)
    {
        foreach (var subscriber in _container.ResolveAll<IEventHandler<T>>())
        {
            subscriber.Handle(theEvent);
        }
    }
}

Thanks... I ended up using a variation of the inversion of control container. — ajeshjohn, Jan 28 '13 at 07:52

score 0 · Answer 2 · answered Jan 25 '13 at 09:24

I think you can use next logic:

 Class1: Interface1 , Class2:Interface2, 

class Manager{
   public Manager(Interface1 managedPart1,Interface2 managedPart2){
        ... some logic for connect to interfaces
   }

}

This way reminds me pattern Bridge, but this is very subjective

Callback interface contract

2 Answers2