business objects versus objects to just show in MVC views

This blog posting tersely illustrates why one might not want to hand one's business objects into a view, but instead craft vanity objects explicitly for presentation and map the real objects to and from them. It touches on AutoMapper and gives a good explanation of how you work with it as a concept, but it also gives an interesting simpler scenario:

1. I need to hand a business object into a view where the object may be edited at a form.
2. Some of the parameters at the object should be strings, but not just any values are allowed. The values should be populated by dropdown lists.
3. A new type, to be handed into the view, will wrap both the business object and enums or something similar used to hydrate the dropdown lists with legitimate options.

Also, in the lightweight, not AutoMapper approach, if I have an object called FruitCake but I wanted to hand a FruitCakeViewModel type into a view in the name of editing a FruitCake at a form, I would have a FruitCakeViewModelBuilder to make a FruitCakeViewModel from a FruitCake and a FruitCakeMapper to cast a FruitCakeViewModel back to a FruitCake. The blog posting suggests these should be instance classes, but I'm going to try to make these static utilities. We are beginning to build out this sort of thing at an app at my work. Let's see how it goes.