PrimeDigit – A Design Blog by Will Shaver

The recently released MVC Beta 1 has some pretty cool features. One of the features that I’ve been using for a while is Model Binders. These are now turned on by default which can cause some problems if you’re not expecting this behavior. For example, say you have an action as follows:

        public ActionResult Binder(Dog dog)

        {

            return View("Index");

        }

Here’s the model:

    public class Dog

    {

        public string Name { get; set; }

        public Dog cat { get; set; }

    }

Calling this action will cause a stack overflow error, as the default model binder will attempt to recreate every dog in the chain.

I would not have noticed this as I use my own implementation of the model binders to provide functionality for pulling an entity from NHibernate that is passed by ID via Ajax. The problem is that I recently switched over to the [Transaction]/ATM method of managing transactions with NHibernate. The problem with this method is that it creates a dynamic proxy of your controller so it can intercept the transaction. In doing so it looses the method argument attributes and then – boom – stack overflow. So now I’m off to hack YET ANOTHER open source project to see if I can get it to not remove the method parameter attributes. :(

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();

        }

    }

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.

If you’re running into this error in NHibernate:

System.ArgumentOutOfRangeException: Specified argument was out of the range of valid values.
Parameter name: Attempting to parse a null value into an sql string.

Examine your mappings for abstract classes that aren’t implemented, or classes that are marked as abstract in the mappings but not in the c# file. I was refactoring out some abstract classes in the middle and forgot to delete the abstract=”true” line in the mapping.

I’ve had it with Foo and Bar. They are right out. For too long we programmers have put up with these sorry excuses for example classes in documentation, lectures, examples, and now that TDD is all the rage, tests.

There is no standard for the relationship of Foo and Bar.

Standards in examples and relationships are full of time-saving goodness. Take for example the Northwind database. Recently there’s been a big push for replacing Northwind with some other database standard. One of the chief arguments against the “Not Northwind” mafia are the magic words, “I’m using Northwind for my database”. *Poof* everyone in the audience knows the relationships inherent in the system.

But Foo and Bar have no default relationship. In the NHibernate project there are 8 different Foo classes, 2 Bars, and 1 FooBar. One of those is actually even in the NHibernate.DomainModel namespace, most of the remainder are in the SpecificTest folder. Different developers have created tests relying on Foo and Bar, and when debugging these tests I have no idea what the properties, entities, or relationships should be.

A sampling of different properties shows that some Foos have Descriptions, while others have Names, Words, Numbers. Some have other Foo as children, while others have Bar as children. Sometimes a FooBar will have a Foo or Bar property….

Enough!

Please, if you submit a patch to an Open Source project… or any project for that matter, don’t use Foo or Bar. Use People and Pets, Cities and Houses, Sales Orders and Sales Line Items, Customers and Orders… any number of obvious relationships that readers won’t need to review the class in order to understand. Foo and Bar slow the reader down… even if you’re the one that wrote it.

W00t! I’ve been accepted as a developer of NHibernate. I’m looking forward to helping this project move along as I discover things that I can fix…

Your website might suck if… it contains the words click here.

…

Of course… now mine does. Doh!

A GUI Interface in VB to Track an IP Address?

Thanks for the ohhh so useful error message SQL server team.

Ass.

I had this cool idea. What if I could hide my NHibernate Entity.hbm.xml files behind their respective c# files in the Solution Explorer. This would tidy things up a bit as I’m getting a bit overloaded in my project at work.

It turns out that this is pretty easy to accomplish… visually. Here’s what we’re trying to accomplish:

Busting out the .csproj file I can edit the file to go from:


<ItemGroup>
<EmbeddedResource Include="Class1.hbm.xml" />
</ItemGroup>

To:


<ItemGroup>
<EmbeddedResource Include="Class1.hbm.xml">
<DependentUpon>Class1.cs</DependentUpon>
</EmbeddedResource>
</ItemGroup>


I even found a macro that does it for you rather than having to hack the visual studio project file directly.

Unfortunately it suddenly broke all my unit tests. Turns out that when adding “dependent upon” it does more than just the visual but actually changes the name (and type?) of the file. Here’s what it looks like in Reflector before:

Here’s what it looks like after:

I spent an hour or so on the MSDN trying to figure out how to solve this problem, but I can’t seem to figure out how to do it. It looks like someone else had this EXACT idea and problem.

Anyone have any ideas on how to solve this?