Help me give Entity Framework Navigation Properties meaningful names, not User{1,2,3,4,...}

Question

I have inherited a medium sized database that we are trying to use with Entity Framework in a MVC2 rewrite we are working on. We used the existing database to generate the data model (.edmx file) and all was good. Until I realized that I could not use the dot notation access all the fields.

appointment.Employee.name   // works fine
appointment.Supervisor.name // this fails
appointment.SupervisorID    // works and is an int

When I looked closer I could see that the first case that worked was most likely a fluke. There are several columns in the table for things like SupervisorID, SecretaryID, DogGroomerID and so, on all pointing to the Employee table and labeled as foreign keys. It looks like Visual Studio almost did the right thing, it just named all this associations after the roles involved, then attached numbers to make them unique. So the folllowing code works:

appointment.Employee1.name // My name
appointment.Employee7.name // My Boss's Name
appointment.Employee5.name // Fluffy's groomer's name

But that really defeats the purpose. So what did I do wrong or what is misconfigured that would make Visual Studio generate such obviously dumb names? I tried changing them in the visual modeling tool and it worked. Renaming Employee7 to Supervisor had the desired effect but that is not really a scalable solution for me to spend the next 10 hours renaming things. What do we do when the database gets revved by the customer in the field again and I need to pull in new schema?

Thanks for any insight and help!

-Eric

Answer 1

In the context of ASP.NET MVC you can use DisplayNameAttribute to add metadata to your model. This blog post can get you started: http://bradwilson.typepad.com/blog/2009/10/aspnet-mvc-2-templates-part-2-modelmetadata.html

Answer 2

Coming back to this the real problem was at a step earlier in the tool chain. We just solved things bu editing the names in the .edmx file and being very careful about merging changes when the database changed. Not a good solution but you can only spend so much time on things.