我最近有一个时间线非常短的集成项目。我们要求使用Biztalk来集中所有与集成相关的流程。
我的项目要求我使用作业队列模式，其中来自采购系统的订单可能导致必须按顺序执行的多个任务。随着在稍后的某些事件上为该订单创建更多任务，这变得更加复杂。
为此创建一个可重用，易于维护和可插入的框架，以便以后与新客户，目标系统和事务一起使用，无法在BizTalk中处理。我改为选择纯C＃+ EF4.1方法，从Biztalk开始创建和执行作业。
基本上，我们已经减少了BizTalk以担任Windows服务的角色。
这是一个糟糕的设计吗？这是一种糟糕的方法吗？我心里说的是，但是面对我所面临的限制，这是最好的方法。
然而，最终，我们正在构建解决问题的软件解决方案。即使这意味着不遵守规范。
你有什么想法？
答案 0 :(得分：1)
我的想法是 - 首先，如果您被迫使用不适合手头工作的工具，除了实现一些愚蠢的政策，那么将其降级为整体架构中的某些令牌功能是可以接受的。
但是，BizTalk是一个具有非常具体的技能的工具。例如，高容量消息传递，非常快速的xslt转换以及易于配置的路由和监视。如果您需要系统中的任何这些功能，那么您可能会比使用BizTalk更糟糕。