开发者

Using WF for Controller/Actions in ASP.NET MVC

开发者 https://www.devze.com 2022-12-12 21:29 出处:网络
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. I know WF is quite heavy and difficult

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. 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.

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.


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. To me, it makes sense to make this UI-specific controller code editable - especially in the CMS framework I'm working on. This is why I want to use Workflow (I have created a jQuery-based XOML editor)

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.

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. 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. I have placed all other service开发者_StackOverflow社区/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. 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.


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). The one that I would recommend is the MVC Storefront series by Rob Conery.

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.


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. 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. 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. 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.

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.


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

0

精彩评论

暂无评论...
验证码 换一张
取 消