CodeBehind

Are there any adverse affects of using a single codebehind file for an entire site (between 4-10 pages)? Or how can I declare a variable on a master page and have it accessed on all the other content pages? I would prefer to use the second one with the master page so that I can keep codebehinds limited to one page per file.

Thanks in advance

To access a variable on multiple pages you need to persist it in either the Session, Cache or Application Objects. (Depending on what visibility it needs.)

If you don't need to maintain it's state (which seems pointless for a "global" variable) you can put it on the master page and access from the contained pages this way. (property may not be exactly right, I'm doing this off the top of my head) Just make sure that the Variable is declared as Public.

DirectCast(Me.MasterPage, FullMasterPageType).VariableName

I am trying to access a sql connection string. I was also hoping to be able to just do my imports on the masterpage but I dont think that is possible either?

Thanks for the information

I am trying to access a sql connection string.


Store it in your web.config file. I can also be automatically decrypted by the .Net framework if you are using 2.0 and encrypt the section via aspnet_regiis.exe or the ProtectSection() Method of the configuration assembly. Tons of examples online :)

I do store the connection string in the web.config file. I was hoping I could do something that after thinking about it is kind of pointless and stupid.

However, I am stuck on whats the best way to do a global function. Preferably in a way where a .dll is not necessary and I could do a single import off of the master page.

A *global* function would go in your Global.asax file...in the application or session events. Regarding a dll not being necessary, I'm not really sure I understand the issue. A master page has nothing to do with importing anything, .Net projects can have external references and in project references. If you want to write a common project, create a common assembly and simply add references to the projects that need it. Having dlls in your bin directory or the GAC for a web application is typical procedure.

If you want a single piece of code that is bound to the application or session instance, use the Global.asax and the session and application objects

Also, if you create a Class in your project that has a Static (err... Shared in VB) Function, you can use it when ever you want. Since it's part of your project, it will be compiled down into the same .DLL as the rest of your web site.

Is that global enough for you?

Global.asax <-- can't be more global than that.

I reserve Global.asax for Application and Session events. (One of the few good holdovers from Classic ASP.)

By using a Class, you get the ability to group like functions together. If you're trying to be Object Oriented (which is what .NET is) you try to code things in a way that they could be reused. I don't see my copying Global.asax from one application to another.

But classes are easy. (although in the long run, I'd do as MKoslof was talking about and complie it as it's own assembly and add it to the GAC.)

copying the Asax file to be used by a whole new separate app would be.. ill-advised yes.

And if the goal is to limit the codebehind file to just one.. yep! a class is the way to go.

thats what i wound up doing after thinking about it some more was create some custom classes.

Just a caveat to think about. Static classes in ASP.net need to be handled with caution, it comes down 100&#37; to what you are trying to do. There are difference between code in the Global.asax and a public static class.

Many threads might be hitting your static class, and always remember static fields and properties ARE NOT thread safe out of the box...you need to handle your own thread safety and when variables are safe to edit and not edit, resetting, etc.

Depending on your static class, it might be "stateful" and not "stateless". If you need a static type class yet "stateful" (an close example of that is the Application object of ASP.net) you might want to consider a singleton and pass the singleton reference around, etc.