[Subjective] Which is best? Bean Binding or Explicit Processors?

[Scott Parkerson <sg...@snortasprocket.net>]

Camel riders,

I've been working on various approaches to a message-driven solution here at $WORK for quite some time, and I must say first of all that I totally love Camel.

That said, sometimes I find myself constantly refactoring my solution, because Camel offers so many different approaches to solve a problem. One particular thing that I'm struggling with is whether or not to refactor a set of subclasses I've written that extend Processor explicitly into something that's more flexible (and even more unit-testable) using Camel's POJO Bean Binding.

For those who have written solutions: which do you find yourself using? Camel's bean binding, or explicit Exchange handling?

--sgp

Re: [Subjective] Which is best? Bean Binding or Explicit Processors?

[James Strachan <ja...@gmail.com>]

On 11 November 2010 15:33, Scott Parkerson <sg...@snortasprocket.net> wrote:
> Camel riders,
>
> I've been working on various approaches to a message-driven solution here at $WORK for quite some time, and I must say first of all that I totally love Camel.

Great stuff, thanks!


> That said, sometimes I find myself constantly refactoring my solution, because Camel offers so many different approaches to solve a problem. One particular thing that I'm struggling with is whether or not to refactor a set of subclasses I've written that extend Processor explicitly into something that's more flexible (and even more unit-testable) using Camel's POJO Bean Binding.
>
> For those who have written solutions: which do you find yourself using? Camel's bean binding, or explicit Exchange handling?


I personally really like beans, as it makes it easy to hide the Camel
APIs from your code and lets you avoid all those lines of code like
this:

public void process(Exchange exchange) throws Exception {
  String foo = exchange.getIn().getHeader("foo", String.class);
  Document body = exchange.getIn().getBody(Document.class);
  ...
}

with just a regular Java method:

public void doSomething(@Header String foo, Document body {
  ...
}

which is way more DRY, much less code and much easier to test. It also
feels a bit like a Processor is kind of a dynamically typed API;
whereas a bean is a statically typed API - so things like code
completion & javadoc are much richer. The bean is also more reusable
outside of Camel too.

-- 
James
-------
FuseSource
Email: james@fusesource.com
Web: http://fusesource.com
Twitter: jstrachan
Blog: http://macstrac.blogspot.com/

Open Source Integration