Window Workflow Foundation (WF) is big, and how CSLA (or your framework) can support it

Window Workflow Foundation (WF) is big, and how CSLA can support it

Note: I use CSLA as the “baseline” architecture for easy discussion. Note that I highly recommend you study CSLA; however I do not use CSLA “as-is” – I really do not like the typed collections and limitations of CRUD things. However, this does not affect my recommendation that CSLA is the best material in the market. Note that in the beginning, CSLA is supposedly an educational anyway.


I posted the following on Rocky's Blog:
http://www.lhotka.net/weblog/DoesWorkflowCompeteWithCSLANET.aspx



A. Window Workflow Foundation (WF) is big

(1) WF is “just” an automation scripting tool, just like VBA.

(2) However, just as we can use VB for application development, we can push WF deeper.

(3) Actually, we have the whole COM, simply for VB (OK, I twisted it a little to make it VB centric, but you know what I mean). Of course, just as we cannot create a COM for every object, there must be a limit how far WF can go.

(4) The scripting is XML based (XAML), however, in theory, it can be written by C# etc. Note that I do not mean the “code-behind”; I mean writing the workflow in C# and the IDE translate it into XML.

(5) The analogy can go further: a new generation of RAD is coming back; now, it is enterprise level, so, let's say it is ERAD. The workflow and its visual designer is the beginning of ERAD. You put this with the whole Office scripting, that is the power of M$! Note that because of WF, it is also the MDA. a WF is a more structured (hence more limited but also more supported) "activity diagrams". Now, the flyweight joins force with the super-heavy weight.

(6) Also, it is a structured (hence more limited but more supported) aop loadtime engine (i.e. emit-style engine).

(7) Also, this is a structured threading engine also. Who needs low level threading anymore!

(8) Also, it is a super-lightweight application server. It replaces EJB session beans! For example, it provides transaction services. Also, it requires you do things in a certain way. It is all similar to EJB. Note that I guess nobody now cares about the entity bean anymore; it is replaced by OR mapping, which will be realized by ADOEF-LING in the near future (if MS screws up again, it does not matter, we have nhibernate anyway).

B.How CSLA can support WF

(1) WF activity is basically the workflow object (“command” object). I believe CSLA should help to make all such object as a workflow activity, out of box.

(2) One deeper WF “customization” of CSLA is to remove those CRUD methods into separate classes. Entities are just entities. Those 4 CRUD methods should be split into 4 activities. In short, together with (1), all CSLA database related programming is in “activities”.

As I have pointed out sometime before, the base of CSLA is command design pattern. WF’s activity is also based on command design pattern. In Java history, command pattern was very popular before J2EE, but has been declining ever since. However, because of workflow engine, it seems that in .Net, command pattern will be the dominant design. Note that J2EE also has workflow engines, but historically, it came after J2EE server, and therefore it is only a feature of application server.

(3) Note that for those pure entity classes, they can use rule engine, instead of CSLA’s rule engine. Note that MS’s rule engine now is very simple-minded, it is not really the “inference rule engine”, but it is still more powerful than CSLA’s. Also, it is everywhere, and it is free. It is going to be ad hoc basic-standard.

(4) For performance, the workflow engine must be a singleton.

(5) The thing that is not touched at all in CSLA is the data-binding related features of those pure entities.