How do you deal with FKs in the Microsoft MVC Framwork

So I am currently working out a thorny problem in office productivity under the Microsoft MVC Framework. As per normal, this is a standard line-of-business, SQL Data, web form kid of a job. For those who do not know about it yet, the MVC framework contains all manner of code generation capabilities for doing a very basic webform. If you use the Entity Framework, a simple right click on a controller method like "Index" can spit up a full list of rows in a simple index view.

This pushes you in the direction of a very specific pattern. You tend to follow the flow and make one controller per major table. This controller has an Index, Edit, Create, and Update method. Each one of those methods has a view. You create 4 views per major table this way.

This would all be wonderful if the HTML generated by the MVC framework was absolutely beautiful and perfect. It is not. It is bare-knuckle and ugly as shit. This makes a clean-up and beautification process absolutely necessary. At the very least, you have to go through and Alias the field names with a friendly name. At the rate of 4 views per major table, we are talking about a significant amount of HTML cleanup here.

Worse still is the fact that this is so highly patterned a type of clean up that it cries out for a better code generation solution in the first place. You can waste a hell of a lot of time, applying and re-applying the same damn HTML changes to every flipping form in your MVC system. You can loose your mind doing such mindless work.

Alternately, you could simply hand-craft a few ultra-hyper-super forms of the kind that ASP.NET was famous form. MVC won't give you any help with this approach. That is a pure DIY.

So which way do you go? I find myself doing both. This is tedious and time consuming stuff, mixed with highly complicated AJAX stuff. I am working a lot of hours on this, and I am going to loose money because my current contract is capped at 40 hours.

So how do you solve this? I am on the verge of saying that you use what's left of the 40 hours to write a code-gen solution that will do an improved collection of 4 views per major table. Those views should be fancy, and they should follow an absolutely consistent pattern. This is good for the developer and the user. Both the users and the developers should be able to discern these clear-cut patterns in the software. Once they get how it works, it should be easy.

If it takes longer than my current pay-time allotted, it matters little. I will make it up in spades on the next assignment. I can leverage this elegant code-gen system to make the next product a hell of a lot faster to develop. Eventually, it will turn profitable.

Memo to Microsoft: The real downfall of the View Generator in MVC lies in the way it deals with Foreign Keys. You know and I know that just about every Foreign Key in every major table references a list of items that constrain its value. Those need to be turned into specific input types. We might need a combo box, we might need a group of radio buttons. Going through every view, finding every FK, and doing that code is a real pain in the wazuski. This is the one clear-cut spot where the MVC framework can be improved.

Basically, I am writing the generator that writes that code right now.