Design Question

smarchetti posted on Thursday, June 22, 2006

Hello.  I running into some difficulty designing my application and I was hoping somebody would be able to offer some advice.  I am developing an application that will display bonus information to all employees in my organization.  Here's some background information.

My organization is broken up by Divisions and Business Units (for example, an employee may work for Business Unit 1 which is in Division A).  Each Business Unit has a set of metrics in which it measures it's performance, so the basic hierarchy is as follows:

Division A
    Business Unit 1
       Metric a
       Metric b
       Metric c
    Business Unit 2
       Metric d
       Metric e
Division B
    Business Unit 4
       Metric f
       Metric g

Metric information is updated and released and the end of each quarter.  The requirements are tricky because each quarter, the structure of the Business Units and Metrics may change.  For example, "Metric a" from the above example might be deleted or moved to new Business Unit for the next quarter.  I will need to display historical information as well as the current quarter's information.

So my object hierarchy will look like this:

Divisions
    Division
       Releases
          Release
             BusinessUnits
                BusinessUnit
                   Metrics
                      Metric

Everything will have a one to may relationship.  I envision an administrator adding a division to the system, creating a release (i.e. 1st Quarter 2006) for the division, adding the business units to the release, adding the metrics to the business units, then publishing the division's release.  After the release is published, a new release can be created and kept "in progress" until the information is finalized and published.

I am running into difficulty determining how to create the object model using CSLA.  I have determined the use cases, but I having trouble finding a way to create the design without using switchable objects.  I do not want to load all of the information into a Division object at once because I will never need to edit all of this information.  I have toyed with the idea of having a DivisionList/DivisionInfo read only list, a ReleaseList/ReleaseInfo read only list, a BusinessUnitList/BusinessUnitInfo read only list, and a MetricList/MetricInfo read only list, but this would seem to be a data centric approach not taking advantage of any CSLA features.

If anybody can provide any guidance on this, it would be much appreciated.  Thanks!

RockfordLhotka replied on Thursday, June 22, 2006

At the risk of sounding flippant, I would suggest that you have prematurely identified your object model. What should happen is that each use case should have an object model, with objects defined to meet the needs of that use case.

Once that's done, and each object's responsibility has been defined within each use case, then you can see if you have duplicate responsibilities across use cases. That can help consolidate your objects together - just make sure you don't start warping the responsibilities to make them match. Either they match or they don't.

Once that's done, you can start to normalize behaviors, which will result in creating more objects - but ones that are primarily behavior-only, and really aren't focused on data so much at all.