I thought I saw a message like this either here or at the West Wind board, but I can't find it now to see the answers. So, even though this is probably been discussed many times before, a question:

What is the best way to create the most reusable/maintainable web sites that consist of what the user perceives as multiple pages?

For example, the simplest example maybe, a site that lets you search a database on one page, display the results on another in list format that lets you select an item, and a third page to display the item.

I've got a couple ideas on how to do this:

1. 3 different Web Forms (ASPX files) for each of the three pages the user sees.

This means that the layout of the site has to be duplicated on each page, or page templates are used, or a user control containing header and footer information needs to be used.

2. All the pages are on one Web Form and Panel's are used with the View state to show the user differenet pages.

This could get fairly complex visually and programmatically maintaining the pages.

3. All the pages are on one Web Form and user controls are either added and remove as needed, or shown and hidden as needed.

This seems to be the cleanest solution in my mind, both for reuse and for maintaining.

However, I'm cautious of this "all on one" thing. At what point do you say, ok, some of this needs to be on its own page. For example, on one of teh sites reusing this code, you say you need to add a login form. Should the login be its own ASPX or just add it to the mammoth one. Where do you draw the line?

Logically, you'd think that all the pages should be broken up, btu then, it seems like you're loosing alot of the programming interaction between the pages. What I mean by that is, with the search and the results on one page, you can easily put your Web Form logic into the search button to populate a datalist on the same page. You'd use the conditions from the search form like objects.

If this were two pages, you'd have to collect the variables from teh search page, and pass them (correct me if I'm wrong) as Form or QueryString values to the results page. Then you'd have to use the Request objects to read them? The only reason I'm hesitiant to do that is it seems like I'm loosing ASP.NET functionality and going back to the classic ASP model.

Thats probably more info than you need, but oh well. Whats the best way, and whats the "appropriate" way?