Workflow and Rich Object Frameworks

Rocky Lhotka claims WF is complimentary of his CLSA.NET framework. His argument can be actually applied to any rich object framework where you put your business logic inside your domain model.

I don't think Workflow by itself will have an impact on those kind of frameworks, but Windows Workflow could (or should?) have it, not because the Workflow engine but because the Business Rules engine.  

When OOP started, the idea was that we will have a class that will be responsible of all the behavior of the related real-world entity. The Customer class would know how to persist itself, how to print itself, how to display itself, etc.

Later, we decided to separate the concerns, and we had the 'Customer Views' to handle the UI logic, the 'CustomerRepository' to handle the persistence logic, and the Customer itself, with the structure and the business logic. This added more complexity, as those classes needs to be synchronized (if I add something to the Customer class, I need to add it in each view, the database, etc), but the reality is that today this is the approach that the industry seems to prefer.

However, why should we keep the business logic in code? Code is hard to change, and business logic changes a lot. If we can have an engine to run business logic, it will be possible to change it easily, even by the end users (as ILog for .NET allows).

Check the Rules Driven UI Example in the Windows Workflow site. Even if that example is not very good from an design point of view, as the rules act on the UI controls, it could act on any .NET object that is bound to a .NET control. For example, you could execute the rules over a DataSet, set the Row errors accordingly, etc.

I don't know how far does Microsoft wants to push the Business Rules Engine, but if they decide to create a world-class engine (I don't have enough experience with the current implementation to know how good is it), then I'd tend to write all the business logic that's possible to write using it.

Now, if you mix this with the fact that OO isn't very good in dealing with Data Structures then you could start worrying about the future of rich object frameworks ;).


  • OO isn't good in dealing with datastructures? Huh?

    Anyway, the downside of having your rules outside the BO's is that you can forget defining a usage of the rules. For example, if you use IoC to inject a validator object into your entity instance, it will used automatically for example, so you don't have to take care of that. By adding code outside the entity, to validate it, you can make mistakes, for example not applying validation everywhere where you need a valid entity (!).

  • > OO isn't good in dealing with datastructures? Huh?

    Read the blog post ;). The fact that we have tools to manage those 'links' does not mean that OO is good for dealing with them. Additionally, when the links change, major changes are needed (I talked briefly about it here

    I think it could be possible to inject rules using IOC, and at the end of the day, if you check the business logic in code someone can always 'forget' and write directly to the database ;)


  • Hector,

    Yes, I agree, but up to now Business Rules Engines for the .net Framework have been expensive and not very popular. WF can help to change that.

  • Do you see WF competing with external rules engines such as iLog for .NET?

  • Not, or at least not yet. I hope it will help making Business Rules Engines more popular, and Microsoft starts investing more in it.

  • Some of these external rules engines can be very expensive. I know when checking out another major rules engine, Haley, the licensing cost was almost $10,000 (if not more). If I can get a rules engine already built in the .NET framework with no additional cost (MSDN subscribers can get all Microsoft software), it will be a win for developers and we would really see WF/rules engines take off.

Comments have been disabled for this content.