"Robert Zurer" <ro****@zurer.com> wrote in message news:MP***********************@news.microsoft.com. ..
Assuming the following to be true:
1 - All business object have a globally unique object id (OID)
2 - All business object descend from ContextBoundObject
3 - All business objects are decorated with a ContextAttribute which
will allow interception of all calls to Set or Add methods.
When a call is intercepted, an entry is made in a globally accessable
Singleton structure which will associate the OID and PropertyName of the
caller with the OID of the object being set.
I think that the problem you are trying to solve is too general.
And even if you do find all references to an employee object,
what will you do if particular reference *is* accessed after the
employee has been removed?
It looks like objects that use employees must be ready to cope
with the fact that by the time they access the employee, it
can be long removed.
Off the top of my head, I can suggest two solutions.
They can be used separately, or together.
1. Use weak references. Each employer should have one and
only one object that it reports to ("the manager"). Only this object
should have a real reference to an employee. Manager can
remove employee, if needed. All other users should
receive weak references to the employee (see WeakReference
class) and be ready that this reference can yield null at any time.
One problem with weak references is that the object does not die
immediately after all real references are gone, so weak reference can
retrieve an employee after it has been logically removed.
Thus, you probably will want to use a Removed flag in your employee
object and an intelligent weak reference class that works along these lines:
class EmployeeWeakReference : WeakReference
{
public overrides object Target
{
get
{
object Obj = Base.Target;
if (Obj == null) return null;
Employee E = (Employee)Obj;
if (E.Removed)
return null;
return E;
}
...
}
}
2. If user objects need to be notified about employee removal,
have an OnRemove event in your employee class. Fire this
event when employee is to be removed.
Don't forget about thread safety.
If your program is multithreaded, remember that an employee can be removed
while some other thread is working with it. Either you need to serialize all
access to employees, or work out some protection mehanism that will
prevent this from happening. Note, that this problem does not go away
even if you use some sofisticated reference-tracking machinery to
find out your references.
Ivan