I need some advice on structuring some business objects. I have a table in the database called EmployeeEvents, this table hold the common information for three type of events (drug testing, alcohol testing and physical). When we enter a physical event I only deal with the EmployeeEvent table. But when entering a drug or alcohol test then the employeeevent table links to one of two other tables, one for drug and one for alcohol.
The problem is this, I can't decide what the best way to structure the business objects to handle the three type of events. I thought about creating an object for each type. The issue with this is when we send a drug test for retesting. The retest is entered into the drug table as a child record of the original drug test, it is also linked to the record in the employeeevent table.
Any advice would be greatly appreciated.
It could be as simple as a "EmployeeTest" object which has a type property on it (i.e. Physical, Drug, Alchohol), and then you could dertermine which tables to update based on the type.
Or.... you might have a base class "EmployeeTest" that defines all the common properties and behavious for all 3 types of test, and then create a PhysicalTest, DrugTest, AlchoholTest objects inheriting from EmployeeTest.
Really depends on your Use Cases - are you likely to need to do different things which each type of test?
Objects should be defined by behavior, not data.
So if your objects have different rules and procedures, then they have different behaviors and should be different types.
I think I have thrown things off by mentioning the tables. I do understand that objects should be definded by behavior and not by data.
My question resolves around how do I set-up a base class for the common code and then inherit from that for each object that I need to create. A class can only inherit from from one base so will I be able to inherit the features from csla.businessbase in the base class into my bo that inherits from my base class? Or am I missing something and making this too complicated?
It is a best practice in OOP to favor composition over inheritance. Inheritance seems like such a good idea, but in most cases it triggers a level of coupling that is counterproductive.
You might find this post interesting:
http://forums.lhotka.net/forums/permalink/37508/37508/ShowThread.aspx#37508
BusinessListBase<T,C> requires that the C type implement
IEditableBusinessObject, which you get from BusinessBase<T>.
But if you want your collection to contain more than one type of
object, then you need a way for BLB to be happy. Since BusinessBase<T>
isn’t polymorphic, you need C to be some non-generic type – like your common
interface.
This is all about polymorphism in the end. Can BLB, and your
code, treat all items in the collection the same, even if they are of different
types? And the answer is yes, as long as they all share a common non-generic
interface.
Okay I am going to create the IEmployeeEvent to hold the common elements. Then implement that into by BOs (Physical, DrugTest and AlcoholTest).
Copyright (c) Marimer LLC