在spring xml中定义Camel路由有什么优点和缺点？
目前我尝试更深入地了解 Apache Camel。如您所知，至少有两种方法来描述路由：Java DSL 和 XML 配置。
Camel的开发人员建议使用Java DSL，因为它的好处是可以更好地集成到IDE中。另一个好处是，您可以使用自己的代码丰富 Java DSL，而无需编写复杂的类结构。如果采用 XML 配置，这似乎是必要的。
您认为 xml 文件中定义的路由有哪些优点和缺点？何时使用 xml 文件定义路由以及何时使用 Java DSL？
Currently I try to get deeper into Apache Camel. As you know there are at least two ways to describe the routes: the Java DSL and the XML-configuration.
The developers of Camel recommend to use the Java DSL because i.e. it has the benefit that it better integrates into the IDE. Another benefit is, that you can enrich the Java DSL with your own code without writing complex class structures. This seems necessary if XML-configuration is taken.
What do you think are the advantages and disadvantages of routes defined in an xml-file? When to use xml-files for definition of routes and when to use Java DSL?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
这在一定程度上取决于您的要求，但几乎在每种情况下，我更喜欢 Java DSL，原因如下：
It depends on your requirements a bit, but in almost every case, I prefer the Java DSL for the following reasons:
如果您使用 Java DSL，您可以利用 IDE 的重构工具和编译时检查。
另一方面，如果您使用 xml 文件，您可以外部化整个骆驼路由并重新路由内容，而无需重新部署应用程序。
If you use the Java DSL you can leverage your IDE's refactoring tools and compile time checks.
On the other hand if you use xml files you can externalize the entire camel routing and re-route stuff without redeploying the application.
如果您开始使用 spring，您很可能会需要实现处理器或其他东西。您有时会需要自定义代码。
此后，您的代码中将混合使用 java 和 xml - 维护令人恐惧。
除了这个java之外，还有：
以充分利用它，我还建议尽量减少使用字符串的端点配置。因此，不要以这种方式创建和配置端点：
我建议单独创建/配置端点：
这比摆弄字符串更不容易出错。
If you start using spring you will most likely come to a point where you need to implement an Processor or something else. You will need custom code at some point.
After this you have a mix of java and xml in your code - maintenance horror.
beside this java is:
to get the most out of it i would also suggest to minimize configuration of endpoints with strings. So instead of creating and configuring endpoints this way:
i suggest do create/configure the endpoint separately:
This is less error prone than fiddling around strings.