我们将开发一个需要基于工作流的ASP.NET MVC 4 Web应用程序。 场景是这样的:
情景
用户通过提交表格请求获得银行贷款, 运营商在他们的仪表板中找到网格中的请求,他们看到了 细节,如果可以,他们将它发送给老板,并将其发回给 用户修复或完成请求,如果没有。老板决定付钱 贷款与否,如果是,价格低于它的资金 部分,如果它超出了某个请求去另一个老板和 等...... ..
要求的
同时运营商可以
问题
在上面的场景中,哪种技术更合适?为什么?
或像以下的图书馆:
答案 0 :(得分:2)
我不会使用BizTalk,即使我多年来一直是BizTalk开发人员,并使用它实现了类似的工作流程。
原因是我得出结论,在BizTalk中对复杂的业务工作流进行建模是对BizTalk真正做得很好的一种诅咒,即高性能消息路由和转换以及主机集成功能。
但是,我也不会使用WF。我认为MS已经让WF不必要地难以使用了。我使用WF3这是第一个版本,所以也许事情已经有所改善。但据我所知,MS从WF4开始删除了状态机工作流,现在只支持顺序工作流。
所以在回答你的问题时,我认为两者都不适合这个目的。
为什么不从ASP.NET MVC,JQuery和SQL Server以外的NO技术堆栈开始。这似乎是目前的MS Web开发标准。可能你已经获得了许可。
即使您似乎预先考虑了您的要求,您也可能会发现您列出的部分甚至大部分要求都可能会发生变化甚至被删除。
首先从一个或两个核心用户故事开始,这些故事可以在小的迭代中快速交付,然后继续添加这样的功能。如果您需要开始查看其他技术或框架,那么就是重新评估决策的时候了。在这一点上,我个人会看到使用NServiceBus sagas作为管理长时间运行流程的另一种选择。
我认为在规划过程中过早做出技术堆栈的决定可能会在很多方面对你不利。
抱歉,我们不会直接解决您的原始问题。