I have to build a new application from scratch, so I want to implement it using MVC3 and try to follow general best practices as closely as possible. However, I'm developing it as a one man army. Does it make more to create the views first so I have some "Mockup screens" then build the Models and controllers? or the other way around?
ASP.NET MVC – Should Views or Models Be Created First in MVC Web Application?
asp.netasp.net-mvc-3mvc
Related Solutions
I think you are looking at this in completely the wrong way. A GUI app and a web page are worlds apart so the exact same definition of MVC will never work for both. MVC is more about the ideal: separating certain parts of the app like display and logic.
In PHP (or the web in general), a View is the web page itself: the HTML output. It's not "live" as per your definition, but you simply click links to go back to the controller (i.e. another page request).
The Controller and Model is where things do differ, like you explained. In PHP the model tends to be the data layer, interacting with the database and so on. But it is still modelling the situation, and the controller still controls the application flow, if only once per page load.
So the name "Model-View-Controller" is perfectly logical, albeit a different implementation in GUI apps vs web apps.
The best thing for you to do is just to start with the default MVC scheme - where controllers and actions are 'allocated' by URL convention, with the first part of the path determining the controller, and the rest of the URL (and the request type, e.g. GET or POST) determining the action that'll be called.
Whilst at first this seems like it must lead to a 'mess' the reality is that most websites don't actually require loads of controllers, and certainly don't require loads of actions.
Sometimes you might wish to do some clever stuff to split one controller into two, whilst keeping the URLs the same - e.g you might have:
~/Products going to ProductsController.GetProducts()
~/Products/{id} going to ProductsController.GetProduct(id)
But then, let's say you have reviews of products too, you might have
~/Products/{id}/Reviews going to ProductReviewsController.GetReviews(id)
This could be legitimate since reviews functionality might require quite a lot of code, which isn't directly related to the products themselves.
That said, the motivation for splitting controllers shouldn't be to keep a code-file small (you can do that with partial classes), it should be to keep to a single-responsibility principle; that is - a controller should have responsiblity for single section of your site. The Users controller should not also be used for your homepage.
Don't spawn a new controller for everything you do, consider it based on the entity that the controller will operate on or provide details of (e.g. products, users etc). Thinking URL-first and then using that as the basis for new controllers is a very good starting point, because ultimately you want your site to be easily navigable by search engines as well as users.
The beauty of MVC, also, is that with the separation of controllers from the route patterns that trigger their actions, you can completely change the URL structure of all your existing code just by changing the routing. For that reason it's particularly important to remember always to use the UrlHelper for generating URLs to other actions, and HtmlHelper's ActionLink and RouteLink operations in views for generaing cross-links; these honour routing, and so take away a lot of the pain associated with re-structuring a website at the URL level.
Best Answer
I tend iterate through both in turns.
I usually start by sketching the model, since at the end of the day it's the single most important thing to get right in the long term.
But I also consider the UI, wondering how the latter impacts the model. There are occasions where the model is right on paper but leads to either or both of UI problems and performance problems. I adjust the model accordingly.
Take users and addresses for instance. The natural idea is to normalize the thing to the point where you've users, addresses, cities, states, countries, and a user2address table for an n-n relationship.
But if you consider UI implications of that and how that could work out in an editor, the last thing you want is a confused user who edits someone's address following and ends up changing the address of many others. You end up abandoning the user2address table, and stick to a user_id field in the addresses (thus a 1-n relationship).
(Don't dismiss the example as silly, I've actually seen this in real life for company names and addresses on a system that had a contact2company table. A secretary changed a company's name and address because a contact had a new employer. This resulted in a near-dup entry in the companies, and incorrectly changed the mailing address of several other contacts).
Point is, there are cases where UI leads to amend the model, and vice-versa.
Another crucial point, which you haven't mentioned but which I think is equally if not more important, are business rule edge cases. In those, "always" actually means "usually", and "never" means "rarely".
For instance, I've seen stores whose orders tables were tied to a single product and two dates (order_date/cleared_date). I said good luck with that if you need an order with multiple products or if a chargeback or partial refund occurs.