Csla & Windows Workflow Foundation

SonOfPirate posted on Wednesday, June 14, 2006

I've been looking into the new Windows Workflow Foundation only to read an article yesterday written by Mr. Rockford Lhotka about Microsoft's announcement from Tech Ed that .NET 3.0 will be the convergance of .NET 2.0 and the slew on "add-on" foundations that have been available to developers for evaluation for some time now - including WF.

Given that this announcement makes it sound like WF will become and official part of the .NET Framework sooner than later and no longer an "add-on" toy for some of us to try on for size, I am wondering what kind of support Csla offers for workflow-oriented applications that make use of the features and functionality provided by WF?  Do we have to make changes to accomodate WF and how will using WF affect the way we make use of the Csla framework?

This can also be extended to Windows Communication Foundation (WCF) and Windows Presentation Foundation (WPF) that are also supposed to become a part of .NET 3.0 as well as the new InfoCard stuff.

I'm hoping Rocky will jump in here and educate us all on what to expect.

thx

RockfordLhotka replied on Wednesday, June 14, 2006

I've discussed this before (but maybe on the old forum).

There are, I think, two primary ways CSLA and WF intersect.

1. You can use a CommandBase-derived object to encapsulate the concept of starting a workflow naturally within the context of your business object model. In other words, the workflow (probably on the server) is represented by an object in your model.
2. You can implement a workflow task using CSLA objects. If you think about a task, it is a clearly defined bit of functionality. What is a use case? A clearly defined bit of functionality. Thus, a task is a use case - so implementation of a WF task is a perfect place to be applying OOD and OOP.

Neither of these should require any changes to CSLA.