ASP.NET Directory Architecture

[shadyness]

I have a fairly easy question that more likely than not has numerous subjective answers, but I need some help nonetheless.

I have programmed in .NET for a while mostly winform applications, but I have never “owned” a very large scale web project before. Well, that time has arrived and now that I am through gathering requirements I was horrified to realize that I couldn’t plan out directory architecture well.

In the classic ASP days I could easily visualize the cleanest structure for includes providing for clean code re-use and separation of file types (img,js,xml,swf folders etc). As the site drilled down the sub directory structure for various site components provided for ease of management too.

So my question is how do most of you design your directories to provide in growth in complexity in your code line for an ASP.NET site? There will be eventually 14 very separate and complex areas (used for financial and OLAP reporting), but a single header file in the ASP days would work fine here (page titles and meta data needs to be fetched from a table).

Any opinions would be great!

<== Some people say they are afraid of heights. With me its table widths. ==>

 

[tperri]

You can have the same behaviors of ASP includes in ASP.Net - You can use Web Controls, or you can just create master Pages with everything you need.

I think everyone does directory structure differently, but I dont see why you can't stick with a system that has worked for you in the past.

 

[BoulderBum]

A good approach would be to put the pages for each functional area into their own directory, then have each use a common MasterPage for the header information (or a user control if you're still stuck with Framework 1.x).

Beyond providing a neat way to organize pages, you also gain the ability to have things like per-directory security configuration through a separate web.config file for each directory.

For example, if you screw up in your coding and link to a "Management" page when the user is only in the "Salesperson" group, then the ASP.NET will run a security check and automatically block the user from accessing the resource/page thus preventing an accidental security breach.

Dynamically driven title/meta tags can be manipulated programatically through Page.Title and Page.Header (or through a Literal control placed in the header) respectively.

Out of curiosity, however, do you have physically seperate pages for each functional area? If so, why dynamically load Title/Meta and if not, the stuff I said earlier about different directories may not suit your needs.

 

[shadyness]

Well, I am thinking very classic ASP here, so forgive me a bit. The pages in whatever subdirectories are realistically content only. The navigation served to the user is dynamically driven from a table based upon login sessions set. So, the navigation, header, footer type files, for me in the past, would have been in an upper tier of the site directory.

I think realistically what I am talking about it more HTML source than anything else. I want a single file for doc declaration and dynamic including. But even that is another question. Is that a good idea still?

For instance, I used to include whatever JavaScript and CSS files were required based upon what directory the user was inside of. Something like this in VbScript:

<% IF session("whatever") = "whatever" THEN %>
<script src="jsfile.js" type="text/javascript"></script>
<% End If %>

<== Some people say they are afraid of heights. With me its table widths. ==>

 

[shadyness]

Oh and yes, the various sub areas will represent diffent pages. Realistically for management sake. I want this to be easy for someone else to follow in behind. Remove whole sections, make large section changes, etc without too much worry of disrupting other areas.

I think it will be helpful for codeline management as well. Keeping the team focused on a single section sub directory for branch releases helps me bite through in small managed pieces. Does that make any sense?

<== Some people say they are afraid of heights. With me its table widths. ==>

 

[BoulderBum]

Probably what you want to do is put all of the common content (navigation tree, header, etc.) into a MasterPage, then have each of the "content files" in the sub-directories be physically seperate .aspx files that have their MasterPageFile attribute set to use your MasterPage.

If all you're doing for the CSS and Javascript registration is changing it up by the directory the user is in, then it would probably be best to have a nested MasterPage for each directory (one which is inside of the main master, and is used to extend it). You can register the css and javascript files via Page.Header.Control.Add() and Page.ClientScript.RegisterClientScriptInclude() respectively.

(See here for an example, but ignore the WebResource stuff:

http://www.codeproject.com/aspnet/MyWebResourceProj.asp)

If registration happens by more than just current directory, you can introduce the common functionality (conditional script registration) in the code-beside of the MasterPage or, probably more appropriately, in a common Page base class you create and use as the superclass for your own pages (which issolates you from any damage if you decide to swap out MasterPages in the future).

Also worth checking out assuming some settings vary by user is the Profile system of ASP.NET 2.0:

http://www.odetocode.com/Articles/440.aspx

 

[shadyness]

Excellent. That is specifically what I was looking for!!!

Thank you very much.

<== Some people say they are afraid of heights. With me its table widths. ==>