流程设计真的是声明式编程吗？
我听某人说他们正在使用业务流程自动化工具（如 Weblogic Integration）作为编程语言（这听起来有点愚蠢）来使事情变得声明式。 然后他们将所有逻辑放入一个进程中，每个 if 和 while。
但是，过程不是一个如何逐步实现目标的实体吗？
对我来说，这使得一个过程变得完全势在必行。 你怎么认为？
I've heard from someone that they´re using a business process automation tool (like Weblogic Integration) as a programming language (what sounds like something kind of stupid) to make things declarative. Then they put all the logic inside a process, every single if and while.
But, isn´t a process a how to step-by-step entity to reach a target?
For me it makes a process completely imperative. What do you think?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
编排语言实际上是命令式脚本语言，具有条件、循环和其他传统命令式结构，通常表示为通过基于流程图的用户界面。 他们当然不会（根据我的经验）实现尾递归函数式编程、向后链接或任何其他在普遍接受的意义上可以合理描述为声明性的范例。
MS Workflow Foundation 被宣传为拥有一个规则引擎，但这相当简单，并且除了以某种迂回的方式外，并没有真正进行前向链接。 ILOG 实际上为其规则引擎制作了一个适配器，专门将其放入 MS 工作流基础中。
其他工作流工具具有更好的规则引擎和适当的前向链接系统，可以将其视为声明性的。 然而，一旦您进入带有循环和条件分支的工作流程本身，您就绝对进入了命令式编程的领域。
然而，一些系统还为工作流实现了基于 Petri-net 或状态更改的标记系统，这可以合理地描述为声明性的，但它们仍然具有与底层系统交互的命令式模式。 它们仍然会更新变量并有副作用。
我见过一两个应用程序（例如用于数据分析的TOAD）实际上使用 MS Workflow Foundation 作为脚本语言。 因此，它允许您向应用程序添加脚本工具，该工具（至少出于营销目的）不需要编程技能即可使用。
在实践中，一种专为编写、编辑和运行 SQL 查询而设计的工具，配备了针对“非程序员”的脚本框架，这让人想知道它真正针对的受众是谁。 作为一种脚本语言，工作流建模工具相当笨拙，并且提供的抽象机会非常有限； 在实践中，基于 .Net 的脚本语言（例如 IronPython 或 Boo），特别是与良好的模板机制结合使用，将是对此类工具的非常强大的补充。
关于此类图形语言的一点是它们不能很好地适应复杂性。 ETL 工具也存在类似的问题。 我见过一个配置应用程序（见下文），它是用 Crossworlds（现在称为 Websphere Integrator）完成的（讽刺的是）。 在启动应用程序的一个月内，很明显图形工作流语言无法随着应用程序的复杂性而扩展，并且基于用 Java 编写的自定义规则引擎和相当大的定制体进行了重新构建。 java代码。
此类问题在 EAI 和 Orchestration 系统中并不罕见，也是SOA在实践中很难实施。 您所做的实际上是将业务逻辑推入一个非常笨拙的编程环境中，而该环境并未得到官方认可。 这在简单的情况下可以工作，但很难在复杂的系统上工作——这在 SOA 圈子里是一个令人内疚的秘密。
尾声：
配置应用程序是一个制定电信服务合同计划（在本例中为移动电话网络）并推送配置信息的系统
基于规则排除各种交换机、计费应用程序和其他应用程序。 它们往往相当复杂。 当您购买每月有这么多分钟和这么多短信的手机套餐时，配置应用程序会将有关您的访问和计费规则的配置信息推送到系统的其余部分。
Orchestration languages are in fact imperative scripting languages with conditionals, looping and other traditionally imperative constructs, typically expressed through a flowchart-based user interface. They certainly do not (in my experience) implement tail-recursive functional programming, backward chaining or any other paradigm that might reasonably described as declarative in the generally accepted sense.
MS Workflow Foundation is advertised as having a rules engine, but this is fairly simplistic and doesn't really do forward chaining, except in a somewhat roundabout way. ILOG actually makes an adaptor for their rules engine specifically to drop it into MS workflow foundation.
Other workflow tools have better rule engines and a proper forward chaining system that could be viewed as declarative. However, once you get into the workflows themselves with looping and conditional branches you are most definitely in the territory of imperative programming.
However, some systems also implement a petri-net or state change based markup system for workflow, which might reasonably be described as declarative, but they still have an imperative mode of interaction with the underlying system. They still update variables and have side-effects.
I have seen one or two applications (for example TOAD for data anlaysis) actually using MS Workflow Foundation as a scripting language. As such it allows you to add a scripting facility to the application that (at least for marketing purposes) doesn't require programming skill to use.
In practice, a tool designed for writing, editing and running SQL queries being fitted with a scripting framework for 'non-programmers' makes one wonder what audience it's really aimed at. As a scripting language, workflow modelling tools are fairly clumsy and offer very limited opportunities for abstraction; in practice a .Net based scripting language such as IronPython or Boo, particularly in conjunction with a decent templating mechanism, would be a very powerful addition to such a tool.
One point about graphical languages of this sort is that they do not scale well with complexity. A similar issue applies with ETL tools as well. I have seen a provisioning application (see below) that was done (ironically) with Crossworlds (now known as Websphere Integrator). Within a month of starting on the application it became obvious that the graphical workflow language was not going to scale with the complexity of the application and it was re-built, based on a custom rules engine written in Java and a fairly large body of bespoke java code.
This type of issue is not uncommon with EAI and Orchestration systems and is one of the reasons that SOA is hard to implement in practice. What you are doing is actually pushing business logic into a very clumsy programming environment that is not being officially acknowledged as such. This will work in a simple case but is hard to make work on a complex system - this is sort of a guilty secret in SOA circles.
Coda:
A provisioning application is a system that takes plans for telecommunication services contracts (in this case for a mobile phone network) and pushes configuration information
based on rules out to various switches, billing applications and other applications. They tend to be fairly complex. When you buy a mobile phone plan with so many minutes and so many texts per month, a provisioning application is pushing out configuration information to the rest of the system about your access and billing rules.
这绝对不是人们在谈论声明式编程时通常所说的意思，即使它有些道理可以称为声明式。
It is definitely not what people usually mean when they talk about declarative programming, even if it some sense can be called declarative.