我从某人那里听说他们使用业务流程自动化工具（如Weblogic Integration）作为一种编程语言（听起来有些愚蠢），使事情具有说服力。然后他们将所有逻辑放在一个流程中，每个if和while。
但是，流程不是一个逐步实体到达目标的过程吗？
对我来说，这是一个完全必要的过程。你觉得怎么样？
答案 0 :(得分：2)
业务流程语言实际上是imperative scripting languages，带有条件，循环和其他传统的命令式结构，通常通过基于流程图的用户界面表达。他们当然不会（根据我的经验）实现尾递归函数式编程，反向链接或任何其他可能在普遍接受的意义上合理地描述为声明的范例。
MS Workflow Foundation被宣传为具有规则引擎，但这是相当简单的，并没有真正进行正向链接，除了有点迂回的方式。 ILOG实际上为其规则引擎制作了一个适配器，专门用于将其放入MS工作流基础。
其他工作流工具具有更好的规则引擎和适当的正向链接系统，可以将其视为声明性的。但是，一旦您使用循环和条件分支进入工作流程，您肯定是在命令式编程领域。
然而，一些系统还为工作流实现了基于petri网或状态更改的标记系统，这可能被合理地描述为声明性的，但它们仍然具有与底层系统交互的命令模式。他们仍然更新变量并产生副作用。
我已经看到一个或两个应用程序（例如TOAD for data anlaysis）实际上使用MS Workflow Foundation作为脚本语言。因此，它允许您向应用程序添加脚本工具（至少出于营销目的）不需要使用编程技能。
在实践中，一个专为编写，编辑和运行SQL查询而设计的工具配有“非程序员”的脚本框架，这让人不知道它真正针对的是哪些受众。作为一种脚本语言，工作流建模工具相当笨拙，提供的抽象机会非常有限;在实践中，基于.Net的脚本语言，如IronPython或Boo，特别是与一个体面的模板机制相结合，将是这种工具的一个非常强大的补充。
关于这种图形语言的一点是，它们不能很好地适应复杂性。类似的问题也适用于ETL工具。我已经看到了一个配置应用程序（见下文），它与Crossworlds（现在称为Websphere Integrator）完成了（具有讽刺意义）。在应用程序启动后的一个月内，显而易见的是，图形化的工作流语言不会随着应用程序的复杂性而扩展，并且它是基于用Java编写的自定义规则引擎和相当大的定制服务器重新构建的。 java代码。
此类问题在EAI和Orchestration系统中并不少见，这也是SOA在实践中难以实施的原因之一。您所做的实际上是将业务逻辑推入一个非常笨拙的编程环境，而这种环境并未得到官方承认。这将在一个简单的情况下工作，但很难在复杂的系统上工作 - 这在SOA圈子中是一个有罪的秘密。
<强>科达： 供应应用程序是为电信服务合同（在这种情况下为移动电话网络）制定计划并推送配置信息的系统 基于对各种交换机，计费应用程序和其他应用程序的规则。它们往往相当复杂。如果您购买的移动电话计划每月有这么多时间和很多文本，那么配置应用程序会将配置信息推送到系统的其他部分，以了解您的访问和计费规则。
答案 1 :(得分：1)
当人们谈论declarative programming时，通常不是人们通常所说的，即使它在某种意义上可以被称为声明性的。