<table>

   <tr class='Row'><td></td></tr>

   <tr class='AltRow'>...</tr>

</table>

To accomplish this I created a helper function in the page code behind:

protected void Foreach<T>(IEnumerable<T> enumerable, Proc<T, int> action){

 int i = 0;

 foreach(T t in enumerable){

    action(t, i);

  i++

}

}

Then in the .aspx

<%Foreach(People, (person, i) => { %>

  <tr class='<%=i%2==0 ?  "Row" : "AltRow"%>'><td><%=person.FullName%></td></tr>

<%});%>

Just what I needed!

Here is an example. Sometimes you need to be able to access properties on objects that you do not know the name of at compile time. A common way of doing this is to have one class that generates delegates which are good for getting a given property from a given target type. Like so

   public delegate object Getter(object target);

   public interface IAccessorGenerator{
	Getter GetGetter(Type targetType, string propertyName);
   }

Once we have this interface defined, we can use it like this:

   IAccessorGenerator generator = IoC.Resolve();
   Getter getPersonName = generator.GetGetter(typeof(Person), "Name");
   Person me = new Person("Mike Thomas");
   string myName = getPersonName(me);

Obviously, this is a poor use since the property name is know at compile time, but it will suffice.

Using C# 2.0 our IAccessorGenerator can be implemented in a couple ways. First, we could use normal reflection:

   public class ReflectingAccessorGenerator : IAccessorGenerator {
        public Getter GetGetter(Type targetType, string propertyName) {
            MethodInfo getMethod = targetType.GetProperty(propertyName).GetGetMethod();
            return delegate(object target) {
                return getMethod.Invoke(target, new object[] { });
            };
        }
    }

This method is clean, easy to understand and very slow.

Another way to implement this method is using the powerful Reflection.Emit. Reflection.Emit allows IL code to be generated and executed at runtime.

    public class EmitAccessorGenerator : IAccessorGenerator{

        private static string GetRandomMethodName() {
            return Guid.NewGuid().ToString();
        }

        public Getter GetGetter(Type targetType, string propertyName)
        {
            //Get the "get" method on the target type
            MethodInfo targetGetMethod = targetType.GetProperty(propertyName).GetGetMethod();

            DynamicMethod getMethod = new DynamicMethod(
                GetRandomMethodName(),
                typeof(object),
                new Type[] { typeof(object) },
                targetType.Module);

            ILGenerator getIL = getMethod.GetILGenerator();
            getIL.Emit(OpCodes.Ldarg_0);

            if (targetType.IsValueType)
            {
                LocalBuilder lb = getIL.DeclareLocal(targetType);
                getIL.Emit(OpCodes.Unbox_Any, targetType);
                getIL.Emit(OpCodes.Stloc_0);
                getIL.Emit(OpCodes.Ldloca_S, lb);
            }
            else
            {
                getIL.Emit(OpCodes.Castclass, targetType);
            }

            if (targetGetMethod.IsVirtual)
            {
                getIL.Emit(OpCodes.Callvirt, targetGetMethod);
            }
            else
            {
                getIL.Emit(OpCodes.Call, targetGetMethod);
            }

            if (targetGetMethod.ReturnType.IsValueType)
            {
                getIL.Emit(OpCodes.Box, targetGetMethod.ReturnType);
            }

            getIL.Emit(OpCodes.Ret);

            return (Getter)getMethod.CreateDelegate(typeof(Getter));
        }
    }

This method is much faster, but can is harder to understand and debug.

C# 3.0 allows for another option. We can build and compile the Getter function at runtime using an expression tree. This gives us syntax that is almost as clear as the syntax from the ReflectingAccessorGenerator that runs just as fast as the EmitAccessorGenerator:

    public class ExpressionAccessorGenerator : IAcessorGenerator {
        public delegate object Getter(object target);

        public Getter GetGetter(Type type, string property) {
            PropertyInfo info = type.GetProperty(property);

            ParameterExpression target = Expression.Parameter(typeof(object), "target");

            Expression getter =
                Expression.Lambda(
                    Expression.Convert(
                        Expression.MakeMemberAccess(
                            Expression.Convert(target, type),
                            info
                        ),
                        typeof(object)
                    ),
                    target
                );

            return (Getter)getter.Compile();
        }
    }

This method is not as simple as the reflecting method, but it is still quite clear and vastly easier to debug than Reflection.Emit.

This is a fairly simple and contrived example, but I think that it is enough to hint at the power that lies in Expression Trees. Some have compared the power of Expression Trees to that of Lisp. Someone else shows how to create extremely fast switch statement (I think this is an amazing example). I am excited to see what new and powerful things that developers find to use this for!

Eventually, I ran across a problem. Many but not all of my entities had CreateDate, CreateUser, RevisionDate, and RevisionUser properties. Others just had a CreateDate and CreateUser but no RevisionDate or RevisionUser. The most elementary way to handle something like this would be to do something like:

Person person = new Person();
person.CreateDate = DateTime.Now;
person.CreateUser = UserIdentity.Name;
Repository<person>.Save(person);

The problem with this approach is that you would have to maunally update the CreateDate and RevisionDate whenever you created or saved an entity. Not good. Option two is to set the CreateDate and CreateUser in the constructor of all entities but that doesn’t solve the problem of the RevisionDate and RevisionUser. In addition you are repeating that code in every entity class.

At this point, I stepped back and asked myself what the best way to do this would be, regardless of the framework:

• Whenever an object is INSERTed into the database and it has a CreateDate and CreateUser they should be set.
• Whenever an object has been changed and is being UPDATEd to the database and it has a RevisionDate and Revision user they should be set.

Having that in mind, I created two interfaces:

interface IHasCreateStamp {
     DateTime CreateDate{get; set;}
     DateTime CreateUser{get; set;}
}

interface IHasRevisionStamp{/*omited*/}

Having applied these interfaces to the appropriate classes I now had to find where I could intercept the nHibernate Save and FlushDirty events. It took me more time that I would like to find this, but in the end the solution (while not ideal) is quite simple. ActiveRecords sets a nHibernate IInterceptor that forwards all nHibernate events to the appropriate ActiveRecord entity classes as long as they inherit from ActiveRecordHooksBase. I had to modify my EntityBase class to inherit from ActiveRecordHooksBase and in my EntityBase class am able to override the OnFlushDirty method:

protected override bool OnFlushDirty(object id, IDictionary previousState, IDictionary currentState, IType[] types) {
     if(this is IHasRevisionStamp) {
          DateTime now = DateTime.Now;
          string userPcid = SecurityHelper.GetCurrentIdentity().PeopleCodeId;

          currentState["RevisionDate"] = now;
          currentState["RevisionOpid"] = userPcid;

          return true;
     }
     return false;
}

In the OnFlushDirty you are able to modify the currentState and any changes you make will be propagated to the database. You also have to make sure to return “true” if you make any modifications.

Once that and the BeforeSave methods were overridden all CreateDates and RevisionDates are set automatically. One great benefit too, is that a RevisionDate will only be updated if the entity has changed.