2

我们将开发一个需要基于工作流的 ASP.NET MVC 4 Web 应用程序。场景是这样的：

情景

用户通过提交表格请求获得银行贷款，操作员在仪表板的网格中找到请求，他们查看详细信息，如果可以，他们将其发送给老板，然后将其发送回用户修复或完成请求，如果没有。老板决定是否支付贷款，如果是并且价格低于某项，则转到资金部分，如果高于某项，则请求转到另一位老板，依此类推。

要求

  • 在每个状态中，可能会附加一些额外的相关数据，例如在发送请求时计算的用户点数。
  • 存在一个流程经理（管理员），他可以在任何地方取消任何请求或将请求传递给他希望的任何人。
  • 可能有多个可用的转换，状态可以沿着它们移动，状态应该检查条件并选择一个转换。

同时运营商可以

  • 在彼此之间传递请求（如果他们被允许），例如如果他们太忙或者他们要去度假（替代）
  • 查看请求历史记录并查看往返中更改了哪些数据（版本控制）
  • 在将请求发送给下一个或将其返回给某人之前写下注释。

问题

在上述情况下，哪种技术更适合，为什么？

  • 工作流基础
  • 商谈

或图书馆，如：

4

1 回答 1

2

I would not use BizTalk for this, even though I was a BizTalk developer for a number of years, and implemented similar workflows using it.

The reason is that I have come to the conclusion that modelling complex business workflows in BizTalk is an anathema to what BizTalk really does well, which is high performance message routing and transformations, and host integration capabilities.

However, neither would I use WF for this. I think that MS have made WF needlessly difficult to work with. I worked with WF3 which was the first version, so perhaps things have improved. But as far as I know MS removed state machine workflows from WF4 onward and now only supports sequential workflows.

So in answer to your question, I think neither are suitable for this purpose.

Why not start with NO technology stack except for ASP.NET MVC, JQuery, and SQL Server. This seems to be the MS web development standard at the moment. Likely you're already licensed for this.

Even though you seem to have your requirements up front, you'll likely find that some or even most of the requirements you have listed are subject to change or even removal.

So start with one or two core user stories which can be delivered quickly in small iterations and then continue to add features like that. When you get the point where you need to start looking at other technologies or frameworks then that is the time to reassess the decision. At this point I would personally look at using NServiceBus sagas as another option to manage your long running processes.

I think making a decision about tech stack too early in the planning process can work against you in many ways.

Sorry does not address your original question directly.

于 2013-09-26T14:35:03.533 回答