简体   繁体   English

在ASP.NET MVC中使用WF进行控制器/操作

[英]Using WF for Controller/Actions in ASP.NET MVC

Edited - Seems that my original question didn't explain what I wanted clearly enough 编辑-似乎我的原始问题没有足够清楚地解释我想要的内容

What I would like to do is use Windows Workflow to handle action requests. 我想做的是使用Windows Workflow处理动作请求。 I know WF is quite heavy and difficult to work with, but I haven't found any other .NET-based workflow libraries that suit this task. 我知道WF非常繁重且难以使用,但是我还没有找到其他适合此任务的基于.NET的工作流库。

Does anyone have any examples on how to do this? 有没有人有关于如何执行此操作的示例? Or has anyone tried it? 还是有人尝试过? Whether or not this is "true MVC" is not important. 这是否是“真正的MVC”并不重要。


Edit: The "fat controller" example I posted was simply an example of one of the reasons why I want to add WF - All other logic is encapsulated in other service/business layers, and the only thing the controller is responsible for is calling these services and determining the view to be displayed. 编辑:我发布的“胖控制器”示例只是我要添加WF的原因之一的示例-所有其他逻辑都封装在其他服务/业务层中,并且控制器负责的唯一事情是调用这些服务并确定要显示的视图。 To me, it makes sense to make this UI-specific controller code editable - especially in the CMS framework I'm working on. 对我来说,使此特定于UI的控制器代码可编辑是有意义的-特别是在我正在研究的CMS框架中。 This is why I want to use Workflow (I have created a jQuery-based XOML editor) 这就是为什么我要使用工作流的原因(我创建了一个基于jQuery的XOML编辑器)

Just to clarify my original question: I'm not trying to move all my business logic into workflows in an attempt to tidy up my classes, I'm trying to move the reusable Controller/UI logic from out of compiled classes into distributable XOML files. 只是为了澄清我的原始问题: 我不是想将我的所有业务逻辑都移到工作流中以试图整理我的类,而是想将可重用的Controller / UI逻辑从已编译的类移到可分发的XOML文件中。

For example, many of the controller/actions I write are: 例如,我编写的许多控制器/动作是:

public ActionResult List(string categoryId) {
  if (String.IsNullOrEmpty(categoryId))
  {
    var data = productRepository.GetCategories();
    return View("ListCategories",categories);
  }
  var data = productRepository.GetProductsByCategory(categoryId);
  return View("List",data);
}
public ActionResult Display(string productId) {
  var product = productRepository.GetProductsById(productId);
  return View("Display",product );
}

These actions are thin enough to be able to be extracted into Workflow Activities which can then be defined via a drag-drop interface. 这些动作足够薄,可以提取到工作流活动中,然后可以通过拖放界面进行定义。

I'm currently working on a custom CMS project and would like to use a jQuery web-based xoml editor I created a while ago to define the actions available in the application. 我目前正在研究一个自定义CMS项目,并且想使用我前一段时间创建的jQuery基于Web的xoml编辑器来定义应用程序中可用的操作。 The developer section of the admin UI is already capable of generating/editing data models and views - I would like to be able to define simple controller actions using the UI as well. 管理员UI的开发人员部分已经能够生成/编辑数据模型和视图-我也希望能够使用UI定义简单的控制器动作。 I have placed all other service/business logic in either extension methods or service classes. 我将所有其他服务/业务逻辑放在扩展方法或服务类中。

I intend to export these as XML-based modules, so they can easily be ported from one website to another. 我打算将它们导出为基于XML的模块,以便可以轻松地将它们从一个网站移植到另一个网站。 Most of the websites I will be creating are very similar, so there isn't a lot of custom code required. 我将创建的大多数网站都非常相似,因此不需要很多自定义代码。

Obviously, some complex Controllers may not be suitable and require their own custom controller class, but it would be useful to be able to simply modify the workflow to introduce, for example, a new "filterByEmailAddress" parameter on WebsiteB, while WebsiteA still retains the original filters. 显然,某些复杂的Controller可能不适合并需要其自己的自定义控制器类,但是能够简单地修改工作流以在WebsiteB上引入例如新的“ filterByEmailAddress”参数将很有用,而WebsiteA仍保留原始过滤器。

This is probably not the answer you are looking for, but if your controllers are becoming overweight this is probably an indication that your application is lacking proper layering and thus your controller is doing too much. 这可能不是您要寻找的答案,但是如果您的控制器变得超重,则可能表明您的应用程序缺少适当的分层,因此您的控制器做得太多。 I would recommend that you take a look at an MVC tutorial using a well-design architecture (with separate presentation, service and data-access layers). 我建议您看一下使用精心设计的体系结构(带有独立的表示层,服务层和数据访问层)的MVC教程。 The one that I would recommend is the MVC Storefront series by Rob Conery. 我推荐的是Rob Conery撰写的MVC Storefront系列。

http://blog.wekeroad.com/mvc-storefront/mvc-storefront-part-1/ http://blog.wekeroad.com/mvc-storefront/mvc-storefront-part-1/

I don't think that moving all your controller logic into WF is really going to solve your problem - you simply need to structure your application in a way that doesn't require the controller to do more than presentation logic. 我认为将您所有的控制器逻辑移到WF并不会真正解决您的问题-您只需要以一种不需要控制器做更多工作的方式来构造应用程序即可,而不仅仅是呈现逻辑。

It sounds like you are packing too many responsibilities into your controllers. 听起来您要在控制器中承担太多职责。 This is a common problem with people who are relatively new to MVC, MVP, and similar patterns. 对于MVC,MVP和类似模式的新手来说,这是一个常见问题。 The tendency is to put business logic into the controllers, which just leads to a messy architecture. 趋势是将业务逻辑放入控制器中,这只会导致结构混乱。

A controller in an MVC is supposed to drive and coordinate your UI, not drive business logic. MVC中的控制器应该驱动和协调您的UI,而不是驱动业务逻辑。 Generally speaking, a controller should do no more than the following: 一般来说,控制器不应执行以下操作:

  1. Handle user actions 处理用户动作
  2. Redirect to views, actions, or return content 重定向到视图,操作或返回内容
  3. Invoke business logic and/or workflow 调用业务逻辑和/或工作流程

There should be very little, if any, actual functional logic in a controller. 如果有的话,控制器中的实际功能逻辑应该很少。 The controller is a mediator between the views your user interacts with, and the "domain" those views are portals to. 控制器是用户与之交互的视图之间的中介者,而这些视图是门户的“域”。 Your business logic, which could be modeled with WF, should be entirely separate and distinct from the controllers. 可以用WF建模的业务逻辑应该完全独立且与控制器分开。 Sometimes you may have "application logic", functionality specific to a particular UI, and such logic should be properly separated from your business logic, either included in controllers or possibly factored into a buffer layer between your controllers and business layer if it is complex enough. 有时您可能具有“应用程序逻辑”,特定于特定UI的功能,并且应将这种逻辑与业务逻辑适当地分开,或者包含在控制器中,或者如果足够复杂的话,则可以将其分解为控制器和业务层之间的缓冲层。

Aim for maximum composability in your design. 旨在最大程度地提高设计的可组合性。 Stuffing everything into controllers is going to give you the least composability and reusability. 将所有内容填充到控制器中将为您提供最小的可组合性和可重用性。 Separating out logic and isolating responsibilities into components and layers will greatly improve your reuse, simplify your code, and make it easier to utilize tools like WF. 分离逻辑并将职责隔离到组件和层中将极大地提高您的重用性,简化您的代码,并使使用WF之类的工具更加容易。

After searching around on search engines/blogs without success, I decided to try to create an example myself. 在搜索引擎/博客上搜索失败后,我决定尝试自己创建一个示例。 It turns out this was a lot easier than I thought - There is still a lot of work to do, but I think the result is ok for a proof-of-concept. 事实证明,这比我想象的要容易得多-仍然有很多工作要做,但是我认为对于概念验证的结果是可以的。

You can find the solution and blog post here 您可以在此处找到解决方案和博客文章

声明:本站的技术帖子网页,遵循CC BY-SA 4.0协议,如果您需要转载,请注明本站网址或者原文地址。任何问题请咨询:yoyou2525@163.com.

相关问题 ASP.NET MVC-如何将参数传递给其他控制器上的操作 - ASP.NET MVC - how to pass parameters to actions on a different controller 在同一个控制器上的多个操作并在asp.net MVC中进行查看 - Multiple actions on the same controller and view in asp.net MVC ASP.NET MVC控制器动作与自定义参数转换? - ASP.NET MVC controller actions with custom parameter conversion? ASP.NET MVC 5 Url重写以包含控制器中的所有操作? - ASP.NET MVC 5 Url Rewriting to encompass all actions in controller? 具有相同名称的ASP.NET MVC Controller操作 - ASP.NET MVC Controller actions with the same name 基于ASP.NET MVC用户的控制器操作特权 - ASP.NET MVC User based Privileges for Controller Actions ASP.NET MVC控制器动作-代码混乱运行 - ASP.NET MVC Controller actions -code runs chaotically 带有POST控制器操作的ASP.NET MVC OutputCache - ASP.NET MVC OutputCache with POST Controller Actions asp.net mvc-在操作之间重用控制器值 - asp.net mvc - reusing controller values among actions 在ASP.NET MVC中,有没有一种方法可以默认情况下不使用AuthorizeAttribute来将控制器操作授权为管理员? - Is there a way in ASP.NET MVC to make the controller actions authorized as Administrator by default without using the AuthorizeAttribute?
 
粤ICP备18138465号  © 2020-2024 STACKOOM.COM