Message Based Queues

question
1

I really like the looks of this project, but tying the background work to method expressions seems really fragile and could encourage bad separation of concerns. Have you thought about how you could queue messages/POCO objects and then register consumers, instead of serialized method expressions? This would allow less worry about method signatures changing between releases.

The difference between.

public ActionResult PlaceOrder(int shoppingCart){
  DoSynchWork();
  BackgroundJob.Enqueue(() => DomainLogic.DoOrderStuff(shoppingCart));
  return View();
}

And:

public ActionResult PlaceOrder(int shoppingCart){
      DoSynchWork();
      BackgroundJob.Enqueue(() => new OrderPlaced(shoppingCart));
      return View();
    }

Again, great work, and I think this is something that .NET really needs because it’s so common and shouldn’t need to be heavyweight, complicated, or something that we have to pay for (nservicebus, servicestack). Look forward to your response :slight_smile:

2

Consider HangFire as a framework for background method invocations only, like persistent and distributed ThreadPool. Yes, it uses message queues, but this technique is encapsulated, and it does not make any semantic sense. What do you do to separate concerns in your source code in a highly decoupled manner? Yep, you use interfaces:

BackgroundJob.Enqueue<IDomainLogic>(x => x.DoOrderStuff(shoppingCartId));

To make this work, plug in your favorite IoC container, and register concrete services for interfaces. You can also put them into some well-known folder, for example, Jobs and tell others to not to change method signatures and type names there. You can also apply versioning strategy for this folder:

  • Jobs
    • V1
      • IDomainLogic.DoOrderStuff(int)
    • V2
      • ISuperDuperDomainLogic.DoOrderStuff(string)

And work with interface implementations to handle either old and new jobs.