Catching "set" operations for exposed reference types (enlist for processing in transaction)

[Anders Borum]

Hello!

I was looking at marking objects with a changed state, once properties have
been changed. The reason behind this is, that I would like to enlist such
objects for processing in a transaction.

The example below illustrates a sample pattern, which is fine when exposing
simple value types.

However, when exposing reference types, it becomes really hard (if not
impossible) to determine if changes to the state of the original object are
made. I have been looking at the implementation details of .NET framework
classes such DataColumn etc., but those only expose value types.

My fealing is that, unless the exposed reference exposes "change" events,
you are blind to any calls (hence potential changes) made to that reference.

I see several answers of catching "set" operations/marking state:

1. Custom Attributes (means calling messages through sinks; slows
performance significantly; inherit from MarshalByRefObject)

2. If using reference types, only use types with "change" events such as
XmlDocument (or your own custom reference types).

3. Don't use reference types - provide developers with parser classes and
ask them to "set" the parsed value as value type back to the original
object.

4. An explicit call to a CmsObject.Enlist() method, that asks the developer
to manually enlist the object for processing. This might look like a good
design, but it asks the developer to remember calling the method (and adds
to the number of code lines - I could provide both: AutoEnlist and manual
using .Enlist())..

5. Your suggestion?

class CmsObject
{
private string _name;
private NodeState _state = NodeState.Unchanged;

public string Name
{
get { return this._name; }
set
{
this._name = value;
this.OnChange();
}
}

private void OnChange()
{
this._state = NodeState.Changed;
}
}

This exercise is mostly for fun; I've been thinking about this for quite
some time and we've had some great discussions on how to implement this with
the current options in .NET (also compared it to other programming
environments).

I am looking for comments on patterns and suggestions, as some of you
hopefully have been doing things like this lots of times

 

[Ignacio Machin \( .NET/ C# MVP \)]

Hello!

I was looking at marking objects with a changed state, once properties
have been changed. The reason behind this is, that I would like to enlist
such objects for processing in a transaction.

I would suggest a IChanged interface , it should be easier later to treat
different types in the same way.

However, when exposing reference types, it becomes really hard (if not
impossible) to determine if changes to the state of the original object
are made. I have been looking at the implementation details of .NET
framework classes such DataColumn etc., but those only expose value types.

You are right it's not possible, not without the colaboration of the
referenced type (if it does implement IChanged is easier )

 

[Anders Borum]

Hello!

I would suggest a IChanged interface , it should be easier later to treat
different types in the same way.

I am already providing the relevant "change" members in a shared baseclass
that all "changeable" classes implement.

You are right it's not possible, not without the colaboration of the
referenced type (if it does implement IChanged is easier )

I am also doing this already, but was wondering if I had missed something.

Thanks for the suggestions Ignacio!