View Models and dependency injection

While working on a LOB desktop application with a lot of CRUD operations using PRISM and Enterprise Library, I have noticed a recurring pattern that seems annoying. For every domain model entity (eg. Contact) I find my self wrapping it with a view model (eg. ContactVM) then I introduce a new ContactsVM (notice the 's') where the latter class accepts a repository interface which is used to populate an ObservableCollection<ContactVM> and for every Contact entity that I read from the repository, I wrap it in a ContactVM which I pass the entity to via the constructor along with other enterprise library services needed by my ViewModel.

The problem is that all my view model constructors started taking this pattern like this:

ViewModel(EntityToWrap e, DependencyFromEntLib, OtherDependencies ...)

Now that is a problem because most tools and libraries require a default parameterless constructor (eg. some commercial data grids need that to provide filtering support), plus you can't use design data to visualize entities because they need parameterless constructors too. and finally the question: What is the right way to build view models and should Entlib services be provided via constructors or via the ServiceLocator ?

The following is one of many different ways to approach the problem.

I prefer view models which are much more lightweight. I then add a class whose responsibility is to compose the view model from one or more sources (e.g. a repository). This doesn't eliminate the problem of cascading dependencies, but it does free up your view model constructors.

It also keeps logic out of the controllers, and allows view models to be reused (when appropriate, of course).

Lightweight view models
Lightweight controller knows how to locate a composer which assembles the view model (you could use a DI framework to setup the composer with all of its dependencies). The controller may play a minor role in the setup process, but it should be kept simple.
Controller knows how the view model should be assembled, and shares that with the composer class. For example, the action might request a summary view which can still leverage the same view model with no children populated.
Composer assembles the necessary information to complete the view model. Composer may use other composers to gather information for which it is not directly responsible. Again, a DI framework can be used here so that these composers are also given the dependencies that they need.
Controller renders the view as usual with the completed view model.

In my opinion, this also provides a better level of abstraction. Just because a view model often looks like a particular domain model, that doesn't mean it will always be the case.

The end result:

Lots of classes (a downside, granted), but minimal repetition of code (i.e. DRY)
Thin view models which are testable (if needed...they may contain nothing to test)
Thin, testable controllers.
Testable composer objects which can be reused for different scenarios because they (presumably) know how to assemble view model(s) for various purposes.
Flexibility to mix and match view models, controllers, and composers to support different scenarios.