Is it sensible to use Windows Workflow Foundation(WF) as a presentation rules engine?

I'm working on an n-tier application that needs a rules engine on the presentation end.

I need to load display rules from a DB into the BLL tier and pass them onto the client. E.g. Item A is outlined in red when propertyX is true, outlined in white when propertyY is true && It should be hidden when neither is true and you do not have the Admin role

The BLL will end up being rules driven at some point, but we will be migrating hard coded logic from the existing client/server app there first.

Looking at WF, it appears to allow me to create and serialise workflows that I can host on the BLL or on the presentation layer.

I expect there to be a large number of rules as different user roles will get slightly different sets of rules for 开发者_如何学Pythonthe 50 odd types of entity exposed to the presentation layer.

Is this a good idea?

Would it be simpler to define a DSL and manage everything myself?

There are two things you should know.

First, please bear in mind that Workflow Foundation is optimized for a very long process that runs in background and it's meant to be synchronous, an activity must wait for previous activity to complete.

Although you can do parallel workflow activity in .NET 4, the execution start in a synchronous state. This will add more service layer for your application, because WF will need WCF layer to communicate well, outside its project boundary.

See this workflow foundation overview from MSDN:

Workdlow Foundation overview http://i.msdn.microsoft.com/dynimg/IC102288.gif

Secondly, large rules of workflows will degrade performance in the long run, unless you really NEED long running process such as approval workflow that must wait for correct person with correct priviledge (or positions) to approve. Workflow Foundation is very good at this, especially in .NET version 4 and above.

This is an overview of Workflow Foundation 4: MSDN Library of .NET 4 Workflow Foundation Overview and you can start from there.

As being used in WPF, you have to call your workflow service asynchronously, otherwise it will block WPF UI thread.

You can further use the new Async API of the next version of .NET 4.0, but this is just a syntactic sugar to ease using always dreaded asynchronous programming.

Therefore I won't recommend Workflow Foundation as a business rule validator. You can simply use the power of data annotations in Entity Framework 4, mapped from your physical database to your business entity layer, then further remodeled to add business logic and rules, and it's much faster.

If you insists, then you'll have to use async code everywhere to achieve complex callback of a workflow in WCF services.

Actually I think that Workflow would be a good fit for this scenario. There are many people who build applications where workflows execute client side and we have good support for this with WorkflowApplication which supports workflows on background threads.

In fact, I wrote the Introduction To State Machine Hands on Lab with this very scenario. In that application a WPF client with the MVVM pattern uses a Workflow in the model to control the behavior of a simulated ATM machine.