My Thoughts on WF
As I commented in a post on Paul Andrew’s blog regarding what WF is and what it is not:
As I’ve been working with WF these last few weeks, I’ve come to form another view of WF and what it means for developers: in a way, it *forces* developers away from some bad design practices since a WF itself has no GUI and no visual user interface.
To expand on that, it forces developers who would otherwise readily hash their ASP.Net and WinForms GUI code in with the business logic to think in a manner that separates the core business logic from the visual interface code.
The number of developers that still write monolithic projects that contain the UI and business logic is still all too high. In studying from simplified working examples in text books, in MSDN documentation, and various articles one finds online, many developers do not gain a good understanding of how to separate the concerns of their code.
The downsides of this approach are immediately apparent after a little exposure to alternative design methods, yet for many developers, they simply don’t see the light and continue to write their data access code right into the Click event of a Button.
I see WF as a way of moving developers away from this model by encouraging developers to encapsulate code in a WF program (a unit of business logic) or an activity
I would like to add to that, that in the end, WF is still “just code” (maybe my perspective is skewed after having written my own workflow engine). Don’t be fooled by the drag and drop UI, the fancy terms (for example, tracking is nothing more than glorified logging that any learned developer could have easily implemented with log4net, a database appender, and a well defined logging policy), and the hype train in general. When it comes down to it, for any significantly complex application or architecture, it still requires writing of much of the same code that you had to write before (and in some cases, you may end up writing more code to build a functionally equivalent solution) not to mention that whenever you adopt such a framework, you must learn the little nuiances and how the product architects intended for you to complete a certain task within the guidelines of the framework.
Just to share my take on it 🙂
Certainly, it is no “silver bullet”, as Brooks would say, but it’s definitely a step in the right direction. I am quite curious as to the actual adoption rate that we will see with WF in the coming months as it offers no immediate benefit (until perhaps we see a market for custom activities much like we have today for custom controls for the UI). To most, it simply won’t offer anything compelling and to top it off, it will require additional training to implement a solution using WF.
For me, personally, it’s been fun picking it apart and seeing how the minds at Microsoft implemented the same functionality I implemented in my own workflow engine that I wrote for our project at Zorch (while certainly less polished, I like to think I was heading in the same direction…and in some cases, I wish WF offered the same features as I had implemented myself (that was my ego speaking ;-))).
