PrimeDigit - A Design Blog by Will Shaver

Sometimes it is useful to create a cache specific to a particular session. I use this for pre-NH cache in my repositories that I can query with Linq before hitting NH sometimes. You could easily modify this to not be templated and instead work for any object...

If you think there is something wrong with this approach please let me know. :)

public class SessionCache<T>

    {

        private ISession sn;

        private IList<T> entities;

        private void ValidateSession(ISession session)

        {

            if(sn == session)

                return;

            sn = session;

            entities = new List<T>();

        }

        public void Add(ISession session, params T [] entity)

        {

            ValidateSession(session);

            foreach (T t in entity)

            {

                if(!Equals(t, default(T)) && !entities.Contains(t))

                    entities.Add(t);

            }

        }

        public void Remove(T entity, ISession session)

        {

            ValidateSession(session);

            if(entities.Contains(entity))

                entities.Remove(entity);

        }

        public T[] GetEntities(ISession session)

        {

            ValidateSession(session);

            return entities.ToArray();

        }

        public void Clear()

        {

            if(entities != null)

                entities.Clear();

        }

    }

I laid this out in more detail on the forums here:
http://forums.asp.net/p/1317154/2610342.aspx#2610342

I thought I'd mention it to this group so that people were aware of this difference between the interaction the old ParameterBinders and Rescues in version 4 and the new ModelBinders and HandleErrorAttributes of version 5.

The new way of doing parameter binding expects all errors to be placed into the ModelStateDictionary specified in the GetValue method.
public override object GetValue(ControllerContext controllerContext, string modelName, Type modelType, ModelStateDictionary modelState) {

The ModelStateDictionary can then be checked in the controller for errors via ViewData.ModelState.IsValid

I think the idea is that multiple binding errors can then be reported to the user at one time:
foreach (var value in ViewData.ModelState.Values)
{
value.Errors.....
}

Unfortunatly our current NameValueDeserializer that is used by the DeserializeAttribute throws exceptions when it encounters errors. These exceptions are NOT caught by Rescues / HandleErrorAttributes. The ControllerActionInvoker (in preview 5) calls

IDictionary parameters = GetParameterValues(methodInfo);

before the try/catch block that passes off errors to the HandleErrorAttributes. So if you're using any kind of attribute deserialization and expecting your exceptions to be displayed all pretty like in your rescues... then move line #177 to line #180 of your ControllerActionInvoker.cs :)

-Will

Looks like the bits were changed some for preview 5 around the action filters. The 'Cancel' property was removed from the ActionExecutingContext. It looks like for my purposes I can use IAuthorizationFilter and FilterAttribute to get at an AuthorizationContext which has the cancel attribute.