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.

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.

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.

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.

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

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.

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?

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.

Remove this comment

Remove this thread

Comments Closed

Comments have been closed since this content was published more than 30 days ago, but if you'd like to continue the conversation,
please create a new thread in our Forums, or
Contact Us and let us know.