On 11 November 2010 15:33, Scott Parkerson <[email protected]> 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: [email protected]
Web: http://fusesource.com
Twitter: jstrachan
Blog: http://macstrac.blogspot.com/
Open Source Integration
