I have some functionality that I want to add to all 6 of the basic business object classes in CSLA from which you derive your business objects. I am subclassing them so obviously this is the best location to put my added functionality.
I would like to only type the code once and then implement it in each class. I cannot inherit from two base classes, so is putting the code in an Interface my only option?
You can't really "put code in an interface"
What kind of functionality are you thinking of? Perhaps that'll help me understand what you're asking. I don't quite understand "code once and then implement it in each class". I assume you mean "code once and then use in each class"?
Outline
In each table in my database, I add the following fields
ReactivatePerson varchar(50)
ReactivateDate DateTime
IsActive Bit (Boolean)
DeactivatePerson varchar(50)
DeactivateDate DateTime
Then in my objects I add the ability to Deactive & Reactivate objects (records) in the the database. This allows me to remove records from showing up without actually deleting them from the database.
Along with this I am going to add is the ability to only show objects where IsActive is True, or only show objects where IsActive is false, or show all objects regardless of the IsActive state.
I could duplicate code in each of my base classes in that inherit from the CSLA base classes but I would rather not.
Examples
So if I tell my Store object to retrieve a store and the object is set to only retrieve stores where IsActive is true and the store in question is not active, then it will return nothing or an empty object.
If I tell my Read Only List Owners Object to only retrieve Owners and it is set to retrieve where IsActive equals false, then it will only show me Owners who are no longer active.
Real Life Need
Here is my real life situation. My company is a large franchisor and does a LOT of statistics with financial numbers from the stores. We have developed a method to share this financial information without actually giving out the financial numbers. We do company wide report every year. Which goes into the historical financial data and retrieves it. So when a store closes, we cannot remove them from the system. They must stay in the system. My solution was to use the IsActive thing outlined above. The reason we cannot go with static numbers is because the calculations may change from year to year depending on how finely they want to divide areas like "cost of goods", "labor costs", etc.
Well this idea bled over into another report system which measures pricing. Now we have historical data about that. This then moved into another reporting system on salary and benefits.
Now we are at a point where they want to keep as much historical (now including contact info) as possible online. So my approach is, rather than deal with it each time I run into I might as well code it into the base classes.
Further Thought
Originally the ReactivatedPerson, ReactivatedDate, DeactivatedPerson and DeactivatedDate were just for niceties. But then a situation occuried to me. What if my user deactivates a Owner who already has 15 old (deactivated) addresses on record. They want to re-activate him but how can the system tell which addresses it should reactivate. Well, all the child objects that were deactivated at the same time as the parent object SHOULD have a very similiar DeactivatedDate value. So you can use that to programatically reactivate a collection of objects back to the situation it was before you deactivated them. You could even do this two-weeks after the event.
I think I have a solution to emulate Multiple Inheritence.
If I create a interface outlining the requirements for my added functionality:
using
System;Then I create a class to hold my code that will be shared:
using
System;namespace
MyCompany.MyFrameworkFinally I subclass from CSLA and include my common code from my IsActiveFunctionality class:
using
System;namespace
MyCompany.MyFrameworkI know this is an extremely simplified example but it demonstrates the basic ideas. I believe this will successfully allow me to emulate the functionality of multiple inheritence.
You could try removing the IsActive data from every table (so its not redundant) and maybe have just one IsActive table, make that correspond to a full blown business object. In the IsActive table you'd have all the rows you have above plus a field for a table name (or object name) and a foreign key column. Make the PK a combination of the foreign key column and the table name. In your objects that you want to be active you could have an IsActive object and expose that with a property.
Either way, remember if you change the IsActive value you want to call MarkDirty().
Copyright (c) Marimer LLC