Rules Driven UI using WF | mwink

UnoriginalGuy

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

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 Wink

mwink

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

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

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

Thanks Moustafa.

Seraph

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

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! Smiley

poonamb

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?