Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

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?

share|improve this question
    
Why do you think it might be better to have the business logic in the database? I imagine it would be easier to build any reasonably complex application in an environment that wasn't designed (for the most part) to store and retrieve data. In either case, I think your question could be improved if it was more about why the two options are still on the table, and less about the abstract definition of each option. –  Jeremy Heiler Jun 4 '12 at 5:11
    
Why would you think an OOP web based application would be bad? There are so many active frameworks and constructs that work to enable that very practice. –  Rig Jun 15 '12 at 19:20
add comment

2 Answers 2

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:

  1. 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

  2. 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.

share|improve this answer
1  
FWIW, a java solution would be Drools: jboss.org/drools. No point in reinventing the wheel. –  Adrian J. Moreno Jan 11 '13 at 17:37
    
@iKnowKungFoo, very cool! –  Kevin McCormick Jan 11 '13 at 20:30
add comment

I would suggest following the 3-tier architecture for this application, this would mean that you will be keeping the user-interface, business logic and the database in different layers. The user interface that will mainly be look ‘n’ feel of the interface, will be the first layer. Then to provide the functional tools to the users and get the inputs/collect data from the users, this should be business logic layer, which will done through classes and its objects & functions. The interaction with the database that can be fetching the data, inserting the data, updating the data or deleting the data should be done through the database layer, which can be handled through SPs and Triggers defined in the database and executed from the classes defined in the business logic layer.

This will make your applications not just robust and fast but will also give you the flexibility of different skill set resources working on different layer like – designers working on the user interface, developers working on the business logic and the database administrators working on the database layer.

I hope this helps.

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.