As a programmer, I like to have lots of little things that do one thing each, not one big thing that does every little thing.

/News/PressRelease.aspx?id=abc123
is so much better than
/page?s=news&pressrelease=abc123

/News/PressRelease_abc123.htm is really nice but requires a bit of work and some rules about the abc123 part.

Hi Andrew,

I agree, your second URL is cleaner than the first, but also consider that:

/news/abc123.aspx

...is more visually appealing than

/news/pressrelease.aspx?id=abc123

...and consider that ASP.NET 2.0 is making possible easy URL rewrites with a single config entry. :)

And consider that with Apache and mod_rewrite, /news/pressreleases/abc123.html is possible from a single script PHP app. Wordpress is written like this and has great URLs.

mod_rewrite allows you to do /news/pressreleases/abc123.html like Rick mentions above, but even better, it allows you to do /news/pressreleases/abc123 (without the extension). Now you can have URLs that are entirely technology independent.

I think what's even worse are pages that continually post to themselves, like in asp.net. I mean you hit the back button and you get this warning content expired message. - Lame!

Totally agree, Jason...but hey, I'd be impressed by say a single HttpHandler and 1,000 Xml files ;)

ASP.NET is not the cause of the content expired warning when you click your back button. It's because the page is set to expire its content immediately. That'll happen with any technology.

It seems to me that programming everything into a single page is making things complex on purpose. Job security anyone?

"It seems to me that programming everything into a single page is making things complex on purpose. Job security anyone? "

No, it is, in fact, a better paradigm. What is a page? A page is a remnant of the old static HTML pages when you could only serve static content that differed by the "page".

Take, for example, a universal control which can control your VCR, DVD player, television, and stereo. Would you prefer to have such a device? Or would you prefer to have 4 devices, one to control each different component? Aren't the actions essentially the same with each device? Both VCR and DVD player require "Play", "Stop", "Pause", etc.; woudln't it make sense to consolidate two controllers into one? Take your televion and stereo. Both have a "Channel Up", "Channel Down", "Volume Up", "Volume Down", etc. Wouldn't it make sense to consolidate the two controllers into one?

Similarly, for any given website with any type of cohesive organization/layout is very similar from view to view (or page to page if you prefer). Consider this blog. The left navigation and top header never changes from view to view. How do we represent this in ASP.Net? Using inheritence. We have a concept of a "master" page which creates a template for us by inserting controls into a control hierarchy. Other pages inherit from this page and automatically gain the left navigation and top header for free. So any given view is really just a slight variation on this master view with a different set of controls defined in a dynamic (view to view) region. So it begs the question: Why would I have 10 different controllers (pages)? Why wouldn't I have one controller with different modes of operation based on a switch("VCR", "DVD", "TV", "Cable", "Stereo" button on a universal remote)?

To me, a single page architecture is more elegant and moves away from repetition. No matter what, so long as you continue to use different pages, you will end up with more repetition than is necessary.

With regards to the URL, it's not at all difficult to translate arbitrary "nice" URLs to "no-so-nice" URLs using custom HttpModule.

Consider another example (sorry, just thought of this a very good example), look at what the Whidbey team has done with Visual Studio.Net as a single interface/controller for multiple "views".

If you install the latest SQL Server 2005 CTP, you might be surprised to find that Visual Studio.Net 2005 is also installed. Why is this? The development team has wisely consolidated the different interfaces into one: Visual Studio. It acts as a controller and operates in different modes, depending on a "switch", the project type. Depending on the project type, you have slightly different menu items, a slightly different workspace layout, and a slightly different set of tools. But the similarities far outweigh the differences. No matter what project type, you will always have:

* "Save" funtionality. In fact, you will have all of the functionality in the "File" main menu item.

* Toolbox functionality. While the toolset will be different for each project type, the toolbox metaphor will always be applicable.

* Property page functionality. While the property set will differ from object to object, the property page functionality is consitent.

* File browser functionality. 'Nuff said.

And on, and on, and on.

With Visual Studio.Net 2003 and SQL Server 2000, DTS package editor/designer is a seperate from Visual Studio. But there's no reason for it to be since it can make efficient use of the same controller with slight variations. As such, you will find that SSIS is now integrated into Visual Studio.Net 2005 and Report Designer is as well (as it was in 2003).

I don't understand why people still choose to make a distinction between web forms and windows forms. While they are two different paradigms, we see that with the right amount of abstraction (AJAX.Net, for example, which further eliminates the stateless, disconnected nature of HTTP), we are essentially dealing with the same programming model from a high level.

User interactions *within an application* simply change the controls in a view, not the page itself. When I click "Done" on a form, I don't need to be sent to "Done.aspx"; "Done" is simply a different *state*. Navigating to a different page for different content is so 1992. Certainly, there are scenarios where it does make sense to have different pages, but more often than not, in web applications, I don't feel that this is the case.

How about /news/pressrelease/abc123.aspx ;)

What is a page? What is a url?

Url mapping clears one side of the question, but the reason I have many pages is because the pages (not the urls) are functional modules.

I don't want if(urlInfo==loginpage) then DisplayLoginPage() else DisplayHomePage()

For the VS.Net paradigm, it sounds like you need to just use frames ;)

"if(urlInfo==loginpage) then DisplayLoginPage() else DisplayHomePage()"

This is a simplistic method of organizing it. http://geekswithblogs.net/sbellware/archive/2005/01/27/21276.aspx

>> "Methods that have switch statements or flat conditional branching are prime candidates for applying a pattern that uses polymorphism. Switch statements and flat conditional blocks are sometimes indicators of polymorphism phobia. Sometimes you have switch statements that aren’t indicators of polymorphobia, like in factory classes. If you're coming from a procedural programming, you wouldn’t have had objects and inheritance and subsequently no polymorphism-enabled patterns like Factory, so some of this stuff might seem like overkill."

Keyword is *Object Oriented* ;)

"For the VS.Net paradigm, it sounds like you need to just use frames ;) "

You miss the point of a single controller that operates in different context based on a switch, the project type. Read the analogy to DVD, VCR, TV, Cable, and home theater controller; it's a bit simpler to grasp because it's physical.

To be clear on the VS.Net point, I'm not asking "how would you emulate the interface?" I'm praising the fact that they *reused* the same controller for different project types/development contexts. VS.Net is the basis for SSIS Designer, Reporting Services Report Designer, and so on.

Instead of having two different views/pages/desintations (i.e. Enterprise Manager *and* Visual Studio), we now only need Visual Studio.Net which acts as a host for the different design surfaces. Similarly, any given view/page/destination only differs slightly from any other one. It will have similar navigation schemes, similar look and feel, similar headers, similar footers, etc. Do you need 3 views/pages/destinations just because you have 3 different content types, even though the visual display of that content is 70% the same? Wouldn't it make sense to reuse the same view/page/destination and simply swap out the content?

Most web sites where you see a single file for the point of entry use an application based MVC paradigm. Such examples are Struts, Fusebox, Maverick, etc.

"Most web sites where you see a single file for the point of entry use an application based MVC paradigm. Such examples are Struts, Fusebox, Maverick, etc. "

Exactly; most in the Microsoft development camp aren't familiar with these concepts/tools. But we see that even Microsoft is shifting developers towards this type of model with their extensive coverage of Patterns and Practices and the new facilities in ASP.Net 2.0 for URL rewriting out of the box.

http://msdn.microsoft.com/architecture/patterns/default.aspx?pull=/library/en-us/dnpatterns/html/ImpFrontControllerInASP.asp

>> "The previous example (page controller) works very well for its intended purpose. However, it is overly simplistic and not representative of most Web applications. To better approximate the overall complexity of such applications, the requirements for this example call for different headers on the pages, depending on the URL and query parameters. "

"But, that's not my thing. As a marketer, I believe in the indirect value of showing a client the site's mere volume, just based on the visible URLs. The site just looks bigger, implying a lot of folders, implying a lot of content."

Guys, you're reading the opinion from a *marketer's* perspective.

"The site just looks bigger, implying a lot of folders, implying a lot of content."

How can you read this line without heaving a big *sigh* for the team that would end up working on this project? That's like saying "More lines of code implies a bigger program which is better and obviously does more." If you can't agree with the second statement, how can you agree with the first?

Pssh ... who even needs a single page? That's a waste! Just dump it all in an HttpModule. If your users still want to maintain static html files on disk, then just stream them out through the module. If you get complex enough, you can event reinvent IIS within a HttpModule within ASPNET within IIS.

Don't laugh. That used to be somewhat common in ASP:

<% SomeCOMObject(Request, Response) %>