I'm working on a web application that is most likely going to end up with a large number of .aspx and .master files. The size is more a matter of scope than a design issue, so this is unavoidable. Are there any good/bad practices associated with the structuring of large projects?
Obviously I have separate directories for resources like Images, Script files, and Stylesheets, but would it be crazy to have a folder for master pages? If I know I'm going to have like 50 or 60 aspx pages, ought I to create a folder just for aspx resources? Taking that a step further, if 10 of those pages are going to be dedicated to a single product, would it be prudent to create a folder inside my aspx folder for ProductA or whatever?
Generally, the consensus seems to be that whatever makes it more readable to the developers (me, in this case) is good, and I know that Visual Studio does it's own thing when compiling anyways, but I've been in the shoes of the next developer to pick up a project so I'd like to avoid looking like a fool if I can. (not that I expect there to be a 'next developer' any time soon)
For things like Master Pages, it's not so important - these aren't immediately visible to clients in and of themselves, so putting them in a subfolder is an organizational task which you are doing to help structure the site in your head, too.
However, for other fixed pages, the choice of folder can be important; for example, if you were to do the following:
http://www.mysite.com/folder/thing.aspx
You have now created a context for your page - the URL is, in effect, defining how that page sits in relation to your site. Further, this context can be used to your advantage in both navigation and search engine indexing.
A concrete example is a site that sells different categories of products; you could put things in subfolders like:
http://www.mysite.com/books/list.aspx - clear that this is a page that lists books
http://www.mysite.com/games/list.aspx - clear that this is a page that lists games
Search engines will then pick up on these categories and you'll be able to link to them in ways like:
http://www.mysite.com/games/ (providing you set a default page for that folder)
In effect, you are segragating your functionality by categorizing what that functionality involves. You are also establishing a semantic relationship between your site and 'games' in the example above.
This is a part of the REST methodology.
In practice, it is much easier to achieve this sort of structure using URL Rewriting which means, as another poster has mentioned, you don't really need to worry about the structure, except for your own organizational efforts.
It also means you can cut down on the number of pages, and, instead load user controls and content based on the URL you are passed.
So structure your files anyway you want, but do think about what your site's public face will be!