Windows Workflow Foundation futures and database access

Ron Jacobs showed a number of really cool new workflow features we can be expecting in the next version of Windows Workflow Foundation during the last PDC in Redmond and Tech-Ed Europe in Berlin. One of the new features he demonstrated where the activities we can use to load data from a SQL server database into our workflow. Most of the new features are really cool but the database activities are not.

 

Why don’t I like the new database activities

With the new ExecuteSqlQuery<T> we are back to typing in a literal SQL string to be executed on the server and the related connection string directly into a workflow. Not only does this feel like stepping 5 years back in time, back to plain ADO.NET, it also means that we get no compile time checking or IntelliSense whatsoever. Given that a workflow should be a high level concept this seems pretty harsh.

These days most .NET developers have gotten used to, and expect, the power and beauty or LINQ with the related IntelliSense and compile time checking. The fact that we can’t do so in a workflow but have to revert back to basic ADO.NET as it was released with .NET 1.0 nearly 10 years ago feels bad.

 

What I do like

There are some good parts though. The fact that it uses plain old ADO.NET means it can use the asynchronous model of calling the database, something still very much missing from the Entity Framework today. Another benefit is we can use any ADO.NET provider out there. So no problems reading data from Access or Oracle here.

 

Conclusion

While the async IO and ADO.NET provider model are nice they don’t make up for the big step backwards by not giving us LINQ, IntelliSense and compile time validation of our queries. So I am afraid I have to give this a thumbs down [:(].

 

Enjoy

[f1]
[f2]

2 thoughts on “Windows Workflow Foundation futures and database access

Leave a Reply

Your email address will not be published. Required fields are marked *


*