Rules Driven UI using WF (Channel 9)

Moustafa has put together this screencast to show off how you can use the Rules Engine capabilities contained in Windows Workflow Foundation outside of a workflow, and leverage it to drive the business logic of a Windows Forms application. Check out the video, and if you're interested in more, then head on over to our community site where you can download the sample .

This is the article that Moustafa mentions that introduces the Rules Engine available at MSDN.

For more information on Windows Workflow Foundation, you can check the following resources:

Follow the Discussion

Follow
Oops, something didn't work.

Try again?

Sign In to be begin to follow these comments

What does this mean?
Following an item on Channel 9 allows you to watch for new content and comments that you are interested in. You need to be signed in to Channel 9 to use this feature.

Getting "follow" information

Stop following these comments

Start following these comments

What does this mean?
Following an item on Channel 9 allows you to watch for new content and comments that you are interested in and view them all on your notifications page.

Removing your "follow"

Setting up your "follow"

Did you know you can
sign up for email notifications?
- Subscribe to this comments

UnoriginalGuy

Jul 09, 2006 at 8:37 PM

Great screencast!

Now I finally understand what WF does.... All this time I've been mystified to what it does new or how it does it differently, and only found the Microsoft articles on the subject even more confusing.

This screencast is a great introduction to the subject, because it shows you just how amazingly powerful WF can be... No more rolling out new applications when a single algorithm or constant piece of data changes, instead just login, update the database and your done! Amazing and powerful.

Thank you.
Beep

Jul 13, 2006 at 1:53 AM

Thanks for this screencast. Whilst the summary indicates the separation of UI from business rules as a benefit, the demo hasn't taken advantage of it. Perhaps a demo where the rules engine interacts with an object which is bound to the UI would be a better scenario. This could better demonstrate the separation of business logic from the UI. Additionally, the Rules could be applied to an object in a web app, web service or windows UI perhaps solving the issue: I need to apply the same business/validation rules in the UI and in the middle teir.

PS. Perhaps I should not criticise and do it myself
mwink

Jul 13, 2006 at 1:05 PM

Beep,

If you want to put together a similar demo, be sure to submit it to http://wf.netfx3.com, and I'll make sure that it gets up there.

matt
christianlott

Jul 26, 2006 at 8:06 AM

ok. I like WF. The demo was pretty clear.

However - hardcoding prices of products makes it extremely difficult to maintain.

Hence, the demo is completely unrealistic.

I this what WF expects us to do?
moustafak

Jul 26, 2006 at 11:09 AM

Hi, christianlott,

I am glad you like WF and the demo and thanks for the feedback. Please note that the sample is for demonstration purposes only to show you how you can leverage WF rules to drive the business logic of a windows form application. WF recommends that you model your application to fit your business needs and if hardcoding the items' prices doesn't meet your needs then you can pursue other options. One option is to create or reuse an internal structure and the rules can lookup values from this structure and manipulate the UI controls accordingly. Hope this helps.

Thanks, --Moustafa
christianlott

Jul 27, 2006 at 9:54 AM

Thanks Moustafa.
Seraph

Jul 30, 2006 at 8:41 AM

This is good, but I agree with Beep in that what's shown here isn't really practical for a production application. I totally understand the idea of presenting something that is simple as an introduction, but I think it should at least be mentioned in the demo.

I have some larger concerns/questions about the included rules editor and the extensibility of the rules execution model shown. I woked on a large winforms application last year for which we developed a custom validation framework. This framework was similiar to what's shown in this screencast, but our rules were almost always too complex to be evaluate with only a single If/Else condition. Our rules usually required broader knowledge of the current state of the application (often beyond the current screen) and would often contain quite a bit of logic.

The very fact that the rules are complex, of course, is why it's useful to separate them from the rest of the application. The real value comes when you create rules that are reusable, and rules that are written directly against a particular UI are not going to be reusable. But I love the idea of having a rules config editor to help you wire up custom rules along side simple conditional rules that can actually be coded entirely in the editor.

I'd like to see a more in-depth screencast that demostrates how you can extend the WF model shown here to handle complex rules, executing against business objects, and requiring broader application state access. Ideally you can do this while keeping the actual UI code just as simple, and the rules reusable (so they can be used on another screen that access the same business objects).
nuclearspike

Aug 28, 2006 at 4:02 PM

I am glad MS is having these WF screencasts. I agree with the other commenters that the demo doesn't show a good real-world example though.

Another problem is the lack of proper separation of the layers: it's tying business-logic directly to the UI, making it brittle and the rules are not reusable (in other forms in the same app or in different apps). I should have an Order object, set up the Rules for that object and instead of manipulating the .text property of the winform controls directly, I should be altering the instance of the Order object that the Order Entry form is presenting (through databinding). Then, due to this separation, the same validation rules and behaviors could be applied to other presentation layers (ASP.NET, CompactFramework) without duplicating all the rules (our apps have a TON of rules that can vary by customer).

If this can be done, then that is the type of screencasts we should be seeing, a best-practices demo, without hardcoded prices and without tying the business logic directly to the UI, but to the underlying objects to which the UI is bound. Otherwise, I'm sure many programmers will end up incorrectly thinking that the way this webcast presents it is the best practice or if they recognize that it isn't, they won't have an example of what a best-practice example does look like.

There should be a set of validation rules you set up for the Model, and the UI should have a way to hook into the results of the validation tests. Ideally the WinForms/ASP.NET/CF controls would all know how to get the message from the Validation engine that the text entered is incorrect with the ability to have a user-defined style applied to the control (red borders, red background, red text or a red dot next to the edit/check box or set up an event handler for ValidationFailed event) with a float-over hint that ties back to the error message in the user's appropriate language. Then you could databind a label to the validation engine results so it could show all the failures on the form in User-readable text format as defined in the Validation Engine of the Business Rules layer, but definitely not the Presentation layer.

For an example of a framework that does this, go here http://www.oakleafsd.com/ and check out MereMortals. While I've not used it, the online screen casts show how the exact same validation rules are used for both the Windows front end as well as the asp.net front end -- coded once. The problem with their approach is that they have to subclass all of the winforms/webforms controls to be able to support the extra features. It would be nice to see something like MM's features native to .NET and could be used in different ways by various presentation layers. The validation error messages should be easily localizable.

The direction we should be seeing from MS is toward finding the best ways to properly separate the layers so that even more code is reusable. The presentation layer should have as little code as humanly possible. Then when we want to switch to Avalon or some other future front end technology, there is very little that needs to be done, if we want to create a simplified version to run on CF, it should be simple.

Let's say I add a new restriction to the Order object, I should be able to add it only to the validation engine then WebForms, Winforms, Avalon and CF forms should all automatically present the validation error to the user without any coding or even recompiling of the presentation layer on any form that attempts to post bad data.

For the best developer experience, the business objects could be a part of an object persistence framework which would allow me to pass an Order object to the form, the form would have a holder for that Order object and then other controls would use that holder as their datasource, with the ability to reference the object properties as a part of what they are bound to. If you look at Delphi's ECO (Enterprise Core Objects) it allows for this, with substantially more databinding ability than .NET. It allows you to write OCL (Object Contraint Language -- which MS was part of developing the standards for, along with Rational) which can do if/then and other control structures, type conversions, user-defined calls, etc to define what is shown in a control. A grid on the order form would then have the grid datasource set to "thisOrder.OrderDetails" and with each column able to reference the different properties/fields of the OrderDetail objects in the OrderDetails collection found on the Order object.

Now that Borland sold Delphi (and it's other IDEs), it'd be great if MS would buy or license the ECO (which is written in .NET) technology from DevCo (the buyer) and make it core to the .NET developer experience.

Sorry this is so long!
poonamb

May 20, 2008 at 1:33 AM

i've a similar windows form application where i am calling this rules set editor in dialog box. i want to edit & create new rules using this & also save this to database.
i am successful in retrieving the ruleset from database & displaying it in rule set editor. but i am not able to save changes made to this rule set using editor.
how to save to SQL database?
eeevans7

Nov 02, 2008 at 10:45 AM

I agree with Seraph. I understand each group within Microsoft putting out demos for each .Net feature and keeping them simle to get concepts across. It would be nice to see a small amount of work go into showing how to do it correctly with the proper separation. This could be done with one field as an example if time and effort is limited. I have yet to see a good reference application written using a mixture of these concepts, features, and practices in a single example. This is especially true for client applications. There are web examples-a-plenty but from the current emphasis I'm guessing Windows.Forms is dead. It looks like either Microsoft employees don't know how to do this or don't want anyone else to know. Thus we end up doomed to salvage projects with countless problems that may have been avoided with a good example of how to do it right.