I have a similar problem with a business object that maintains data on teachers training courses. In some cases it has to deal with course dates, in others with delegates and in others with the course prospectus. All of these involve their own tables and complexities.

My solution is to create a base business object that contains core methods and properties that all are likely to need. I then create sub-classes for the major specialised activities. These add in their own methods and properties to do what is special to them. That way one specialist area does not need to load up resources for another that it will never use.

Finally I have a factory class that creates objects for the application, using the class that is appropriate for the current task.

Using this method you often find two things. one is that you place the methods wrongly. I find I put them in the sub-class only to find I need a more general version in the parent class. As I write all my business classes in prgs this is a simple mattter of cut and paste in most cases.

The second thing to watch is that you need to make your processing very fine grained. You need to split processes down with each part performed in a separate method, so that sub-classes can easily replace only the bits that they want to do differently.

Best regards

Andrew