We've been tasked with creating a web based workflow tool to track change management. It has a single workflow with multiple synchronous tasks for the most part, but branch out at a point to tasks running in parallel which meet up later on. There will be all sorts of people using the application, and all of them will need to see their outstanding tasks for each change, but only theirs, not others. There will also be a high level group of people who oversee all changes, so need to see everything. They will need to see tasks which have not been done in the specified time, who's responsible etc.
The data will be persisted to a SQL database. It'll all be put together using .Net.
I've been trying to learn and implement OOP into my designs of late, but I'm wondering if this is moot in this instance as it may be better to have the business logic for this in stored procedures in the DB. I could use POCO's, a front end layer and a data access layer for the web application and just use it as a mechanism for CRUD actions on the DB, then use SP's fired in the DB to apply the business rules.
On the other hand, I could use an object oriented design within the web app, but as the data in the app is state-less, is this a bad idea? I could try and model out the whole application into a class structure, implementing interfaces, base classes and all that good stuff. So I would create a change class, which contained a list of task classes/types, which defined each task, and implement an ITask interface etc. Put end-user types into the tasks to identify who should be doing what task. Then apply all the business logic in the respective class methods etc.
What approach do you guys think I should be using for this solution?
Best Answer
If you're going with a Microsoft solution, one great option is to use Windows Workflow Foundation. It already has tons of features to develop complex workflows like the ones you've described above. It's already built into the .NET Framework, too.
Developing a WF application basically has two parts:
Develop the "host" application, like an ASP.NET application. This has the responsibility of loading and unloading data from a database, as well as providing a user interface (like showing a list of workflows in progress, showing assigned tasks, etc.). http://msdn.microsoft.com/en-us/library/ms735891(v=vs.90).aspx
Design the workflows. The workflows can be designed in Visual Studio (similar to developing a Windows Forms application or Visio document), designed entirely in C# code, or in XML. Your host application will then load these workflows and be able to manage and kick off new instances of them. http://msdn.microsoft.com/en-us/library/ms734628(v=vs.90)
There is a bit of a learning curve, but ultimately it will save you plenty of time having to redesign a workflow solution up from the ground up, letting you focus (mostly) on coming up with great and flexible business logic.