search

mhinze / ShortBus

In-process mediator with low-friction API
MIT License
210 stars 41 forks source link

Shortbus distributed as a code file a la PetaPoco #14

Closed mhinze closed 10 years ago

mhinze commented 10 years ago

I think it may be best to distribute ShortBus as a single code file like PetaPoco and others.

Reasons:

  1. While implementing mediator is a common task in many projects, it's also common to need slightly different changes to the implementation. For example, in my current project we do not need the non-async methods. Some folks may want to do something fancier like log all requests. I can see a lot of cross cutting concerns that, if implemented in ShortBus proper, would cause bloat.
  2. ShortBus is a very simple thing, it is not really doing that much on its own. It started as a gist, actually, and doesn't really have the hallmark of a useful library - it's just a simple, single implementation of a design pattern.

Counter-arguments:

ShortBus is pretty easy to get up and running as is. We could bake in support for cross cutting concerns that could be nice, and we have managed to make something pretty cool in spite of all this.

I'm really on the fence. Thoughts?

zachariahyoung commented 10 years ago

I'm not sure I like this idea. Are you thinking you would just put all the code in just in class file?

mhinze commented 10 years ago

Yes. Thanks for your feedback, I am on the fence about this.

dvins commented 10 years ago

Given that most implementations will simply use NuGet to pull a compiled flavor of the library I am not certain what advantage this offers. From personal experience, the only real change I have needed outside of adding multiple handler support was hacking up a copy of ShortBus to support using AutoFac as a container, something which is no longer needed.

jrnail23 commented 10 years ago

In my project, I've been eyeing a lot of those cross-cutting concerns as well. One of the biggest reasons I went with a message-based command processor was to take advantage of a pipes & filters model. I currently have use cases for per-use case authorization, security logging, and eventually, wrapping the pipeline in a unit of work (instead of Session-per-HttpRequest in my MVC app).

So I was naturally looking toward working that stuff into my current implementation. And since I do already have a working implementation, I don't think I'd be very interested in the single file approach. I do, however, enjoy deleting code and outsourcing responsibilities and workload to the OSS community ;-)

zachariahyoung commented 10 years ago

Some of the cross cutting concerns could also be handled with AOP.