Very often I need to pass "complicated" data to my views: different database objects, classes etc. And I'm tired of creating dozens of classes-helpers like.
class StatsPageViewData
{
public User User { get; set; }
public Something Something { get; set }
// blah blah
}
Of course I can't just use ViewData["something"], it's just not as comfortable.
So my question is, is there any way to make this process easier, to automate it somehow?
Use a plugin such as ReSharper that help you create these helper classes.
Start by using the classes and properties. This will marked them as missing in the editor, you can then use the plugin to create classes and properties, making the creation of helper classes much faster than doing it the other way around.
I think the model-per-view pattern is a best practice. You can try to use inheritance and composition to share model components where possible (keeping your code DRY), but I've only had limited success with even that. To make the transformation from your view model to your business model easier you might try something like AutoMapper. I'm too far into the only big project that would benefit from it to apply it, but it's on my radar for something to try to ease the process.
View model should rarely be just a collection of domain classes. First of all, putting domain classes into view model is a big topic; many think that you shouldn't do that. Your view probably doesn't need full User instance but only a name. If you keep full User instance in the view model it hides real view model intention, makes it hard to re-use, and so on. You probably better have string UserName property that properly formats the name, instead of accessing User properties in the view and formatting it there.
That's a theory and no-one has to follow it; but it's good to keep in memory and try to achieve.
Second, your view models shouldn't be just collections of domain classes because they should provide view semantics - for example, validation attributes and additional presentation logic. You can have aggregate properties that provide select lists' data, formatting, and so on. Another example, the POST view models can have methods to convert raw form data to entities.
You should move some presentation logic from views and/or controller into view models - formatting, properties that are only needed by views, and so on. Controller should not convert entity collection into view model data collection - view model should do that. View should not convert format User into single name and address string - view model should.
By doing so, you won't be tired of making "view model" classes because they won't be dumb no more, and your work won't be dump and/or repetitive. The view model classes will be as important as other classes in your application.