For the most part, I use a handful of layouts for each site, then each public method in each controller loads its content into one of those layouts. The layout is just a view which loads other views and specifies one or more content region(s) that the controller can set (and those content regions will usually be set to views). In most cases, I have a common header and footer that is used in all of the layouts for a given site, so the layout usually just changes the area between the header and footer.
My common header has a number of variables which can be set by the controller, including the page title and various metadata, information related to mobile icons and the favicon, etc. I output the link element(s) for the CSS in the header, and the script element(s) for the JavaScript in the footer.
Since a lot of the metadata is not set on some (or most) pages, the relevant meta elements are only output if the values are set. Usually I have some scripts and stylesheets that are loaded throughout a site, so those are loaded into the header and footer at the site level, but the controller or method may add more files, which the header/footer will output.
One of the drawbacks to doing things this way is that the header view is usually loaded before your content view, so your controller has to manage the variables used in the header, and modifications to those variables in your content view (which isn't a great idea anyway) won't be reflected in the header. I usually run up against this when I want to add a CSS file wherever a specific view is used, and don't run a search against the codebase to find other views in the system that also loads the view. That, of course, is one of the things that will lead people to suggest not loading views from views, but I would just suggest limiting the practice, so you don't end up with unmanageable nesting of views within views.
