A lot of the blogsphere articles related to CQRS (command query repsonsibility) seperation seem to imply that all screens/viewmodels are flat. e.g. Name, Age, Location Of Birth
if anyone is actually saying that your viewmodels should be flat, they are either oversimplifying their example or they are talking a bunch of nonsense. hierarchical data is not bad and should not be avoided in your viewmodels.
there really are no 'best practices' for this, though. it's all very subjective in how you load up the data. you need to find a solution that works well for your current team and system. and you should also understand what other options are out there because you'll probably run into a situation where your current solution is inadequate.
here are some of the ways I handle this, depending on the application i'm working on, in C# / .NET:
Datasets and straight ADO.NET, and bind the dataset directly to the screen's controls ** write straight SQL code to load the dataset ** use views in the database to load the dataset ** use stored procs to load the dataset
NHibernate and DTO / Viewmodel objects ** i typically use views when going down this route - I'll create a suite of views on top of my domain's schema, that denormalize the data into the model i need, and then use NH to load it up via a second set of maps
DTO / Automapper from domain model ** i don't like this approach unless I know that I already have everything from my domain model loaded in memory. i'll use a tool like Automapper to transfer data from my domain model into a DTO / ViewModel
i'm sure there are other options, but these are the three that i use most often, in order of how often i use them. they all have their own cost / benefits. but the important thing to understand is that you can and should retrieve the data in a manner that makes it easy for you to populate your screens.