Is it appropriate to model a workflow as a class object?

onurerdem

New Member
A typical workflow needs to be implemented that can be summarized in the following steps: 1) Query the database for the appropriate data, 2) perform analysis on the data (such as aggregation), 3) deliver the data to a front-end system for formatting and display to the user.I can implement the workflow with a linear, in-line code approach easily. My struggle is coming up with the best way to code it for re-usability and scalability. Specifically, I have been exploring the idea of having a class object that encapsulates the entire workflow.The workflow class object would have these methods (and the workflow would be executed in this order):
  • getData (build query string, query database, get the results)
  • initializeDataModel (initialize a nested-hash-style framework)
  • populateDataModel (insert the getData() results into the data model)
  • analyzeDataModel (perform analysis on the data in the data model; analysis results are stored in the data model)
  • packageDataModel (return the entire data model or a subset of the data model)
The thing is, the workflow itself is fairly rigid and there typically is no need to invoke intermediate steps independently. In effect, all those methods could be private, and the class would simply have one public method called something like runWorkflow(), that runs through all those private methods.It would essentially look something like this:\[code\]$myWorkflow = new Workflow(<parameters*>);$output = $myWorkflow->runWorkflow();\[/code\]*Parameters that define the query to be executed and what kind of analysis needs to be performed on the dataIt feels like I'm using the class as more of an encapsulation mechanism rather than using a class for what it is actually designed for. I'm struggling to understand whether this is the right approach to take. If not, what would be a more appropriate implementation of the workflow? Industry standards?For reference, my project is PHP/JS/HTML... but I'm more interested in the implementation theory.
 
Back
Top