Hi Goran,
First, if I can suggests some terminology clarity...
I was originally confused by your use of Business Model and this being cross-posted in the Project Management area. A Business Model is typically a description or concept for how an organization (or an initiative) expects to generate revenue or value.
A Business Process Model is the definition for how the various functions within an organization interact with each other and process inputs to add value within the enterprise activities to satisfy customers and generate revenue.
Now, what you seem to be describing is an Application Data Model, and you seem to be seeking advice as to whether these metrics about the financial transactions should be stored in tables or generated at run time from procedures and calculations.
Assuming this is the case, my suggestion is to keep them as real-time calculations unless:
* The complexity of the calculations and/or quantity of data (considering data growth) would produce exceedingly long execution times, or
* You intend to provide some sort of business intelligence reporting, in which case the calculations might need to be trended over time or sliced-and-diced like a pivot table.
The two conditions, however, could have different approaches. For the first, you need to figure out how to pre-cache the calculations or perhaps store running figures and then just increment the calculations by-request. This might result in relatively simple data tables to store partial, current results.
The second scenario, however, will require more thought into how to dimension the tables so that you have the proper trends and drill-down categories.
And in either case, you'll need to figure out how the processing is initiated to populate the data: manual update by the user, automatic launch or termination processing of the client, or completely separate scheduled batch processing, or...
As for classes and programming structure, you seem to have really two paths to consider: first, what is the functionality needed by the user to interact with this data? Is it a static report, or an interactive pivot table-like thing? What types of filters and sorts will be allowed?
Then that will drive considerations of the data needed to support these use cases. As Jaime suggested, then this becomes a relatively simple processes of Model-View-Controller to give the user what they need.
However, that doesn't address the logic and rules needed to get the data into the proper shape to feed the reports. If you take a fully automated, batch route - or some real-time caching scheme - then you don't really need a "View" to manage the data - just your Model and Controller.
So, without knowing your existing app and your requirements, I can't make more detailed suggestions on what classes you need - but as I see it, these are the broad categories of classes you'll need to design.
Main Topics
Browse All Topics





by: jaime_olivaresPosted on 2009-07-01 at 16:12:45ID: 24759107
I think reports shouldn't generate business classes, just fill an array with data from the Business Layer.
These arrays are passed to the presentation layer to be displayed as a report.
Report arrays can be made of pure string, or other fundamental types by declaring an array of objects.
The presentation layer can interpret array types for proper formatting and alignment.