Programming structure...

Programming structure...a hot topic at my workplace.  We've fought over this topic for the last 2 years.  Here's the deal.  Two different approaches are mentioned. 

The first, the “Control Structure”, is a central area where everything passes through it.  Think Fuse Box methodology if you are a Cold Fusion developer.  In the old days (yeah...ASP 3.0), we would use a central page (main.asp) and pass an action query string value through it (main.asp?action=ShowUsers), which would call a sub or function from another page (users.asp).  The other page would be a gathering of functions, subs, classes that were specific to a function in the program.  This works great (especially for troubleshooting), but is hard to follow through if you are not used to it.  In the .NET realm, we have come up with a similar method of using a default.aspx page but plugging user controls into it programmatically.  I like this method, but to me, it seems slower and more clumsy in testing.  Sure, it's clear and concise, but is it the best use of .NET?

The second method involves a page-for-page approach.  Microsoft demonstrates this through several of their .NET code examples.  Each section is its own page (users.aspx, admin.aspx, etc.).  I recently finished a project where the deadline quickly approached and I used this method.  The project went smooth and we've since added on some functionality and it was simple to do so.  I don't have issues with this approach, but other developers in my group do.

What structure do you use for a web project?  Have you come up with your own methodology (per se) for the layout (structure) of your applications?  Is any of our approaches bad or good in some way?  I'd like the community to speak out on this one.  Not very many folks speak of structure (but do speak of code and samples).

3 Comments

  • What I think you're referring to is a Page Controller pattern - where one page acts as the Controller for diaplyed information - a good example of this is the IbuySpy Portal (which became the Community Starter Kit). THis approach has many benefits when using User Controls - as layout can be defined separately from what essentially becomes a template page.

    A page-for-page approach is interesting and you can design this as a hybrid of Page Controller (you can for example has a common Base Page class which is used as the parent class for each page - this enables common functions; like security etc... to be shared whilst retaining the flexibility of having different physical ASPX pages).

    In the end though, it really depends on what you're doing - I typically have a single page (recently following the MasterPages templating approach - which will become more common in future) which loads in UserControls on demand. This way, I have only a single template to control global look and feel but have the flexibility of having individual user controls to prodive the UI elements...(check out the .TEXT source for a fairly cool example of this method - doesn't use MasterPages but does use a nice templating system with a very MVCish approach)


  • APP

    --FOlder (relates to a process or major unit)

    ....Page 1 (does one task)

    ....Page n

    ....Default Page ( menu for this area or re-dir to main page)



    FOlderName is always descriptive.



    thats in general what I do



    App is the app root with the .config and so on.

  • I use the more central approach favouring use of a HttpHandler for each extension, and a HttpModule for authentication. This is largely because I normally stick to XML/XSL sites driving off a central link manifest.



    It's very rapid to develop, and very extensible. The significant downside to this approach however is in doing so I effectively cut myself off from any advantages offered by ASP.NET such as controls which I invariably end up reiventing myself to some degree in the XSL.

Comments have been disabled for this content.