Ask YC: is MVC the best solution?

Caveat: My MVC experiences have been mostly with Java (Struts) and Python (Django) Then to get into your actual points:

1) The view CAN do the work of determining what will be shown. To quote the Django site: "In our interpretation of MVC, the "view" describes the data that gets presented to the user. It's not necessarily how the data looks, but which data is presented."

2) Anything that is a common widget should be abstracted and included on the page in some sort of "include". Either have some sort of base page that does the work, or on the individual pages do some method of "include". This really doesn't relate to MVC, other than your point about adding the data to your context/session, which should again be done generically and non per-page.

3) The general idea for any MVC system is to have the flow go through one controller. This controller may delegate to sub-controllers, but the idea is everything goes to one spot.

4) What is the best solution? There are many good solutions for writing a web app.

In Rails, you don't necessarily have to have a monolithic view. On more complex sites, you use fragments, called partials. Sidebars can be easily created by having a "shared" view directory full of partials. Further, there is a content_for helper in Rails views. Views render late; you can set an instance variable in the subviews that will affect what gets rendered in the layout. Trying to keep track of that can get hairy, so content_for abstracts that for you. Combined with the partials and the before_filter in the controllers, you can get a view to produce a number of things without having to resort to pulling DB info inside the views -- that reminds me too much of the bad old days of PHP.

In the logged-in users example, in what is normally in the sidebar, you use a render :partial => 'shared/users' if @users; then add a before_filter in the site-wide application layout to pull in the data if someone is logged in. A more complicated example is to render a "sidebar" partial, which renders more partials depending on some array of sidebars you want to display ... then use a before_filter to figure out what you want to populate the sidebars with. Any controller or actions can override or add to that sidebar array.

The main thing that sucks about this kind of organization is having the code scattered in a number of different files. This is where using an editor that knows the relationship between the files is important -- you can hit some key combination and jump between the different fragments without having to hunt them down in the file browser.

The controller is doing the work to determine what will be shown, yes. I meant once the controller determines which view should be used, the view then can manage the specific data being shown.

Django does separate the view into a 'view' and a 'template'. One does your work, and the other does the displaying.

If you, as you suggest, have the view (essentially a glorified HTML template) request the data it needs (e.g. from multiple sources), then your data-selection and visual-presentation become tightly coupled. (The point of a view is that you can have multiple views of the same data). If the original view is handling things like data-selection and complex control flow, then when you want to create an alternate presentation of the same data, you'll end up copy-and-pasting code (c.f. "Don't Repeat Yourself").

So the best solution is to get a really good feel for separation of concerns, code-non-duplication, etc., and then organize your code accordingly. When using MVC, use every bit of it to keep your code simple and decoupled; if you just slap code into units called "models", "views", and "controllers" wherever you like, then you will receive NO BENEFIT (or negative benefit!) from using MVC. But, used properly, it can be a powerful tool.