Common functions

Pete submit an interesting question on the mail list


Hi everyone

This probably a trivial question but here goes anyway.

Most web applications have a need for a "repository" of common functions, ie
user defined functions that are called from most pages.

In classic ASP this was accomplished by creating an include file with
numerous common functions and subs and then "including" that file in the
pages that needed access to any of those functions.

ASP.NET follows the OOP paradigm which involves a major brain shift when it
comes to programming web pages.

My question is how do we now provide those common functions and subs?
Do we have to create instances of classes and execute instance methods every
time or is it acceptable to create a "common" class with a whole bunch of
shared/static methods to be called as instance methods much the same wasy as
math.cos()

For instance, I might have a function that formats a date object in a
particular way and returns a string....

Function MyDateFormat(ByVal pDate As Date) As String

This function is called on most pages so what is the best place to put this
function? Is it necessary to instanciate an object just to perform this
function of would it be acceptable to use a shared class method in cases
such as this?

Thanks in advance
Pete H

It's true that in classic ASP, the way to use common routines is most of the time an Include at the top of each pages.
Now .Net offer more richer things, like user controls.

For common routines, the path I take is to have as much as possible the use of some helpers like the excellent Data Application Block, in complement of each of my projects.

And some shared methods that I setup in a class file or eventually I add a project to my web project to include some common resources there.

It would be interesting to know how other developers deal with common library, because it's not any more simple as it is with ASP.


 

5 Comments

  • This is a question which I've puzzled over as well, the general advice about static methods is 'don't use them to group a bunch on unrelated function together for convenience' umm...yes...well I've yet to come across a project which doesn't do just that. Most of my prjects has a 'Common' class somewhere about which has a whole bunch of 'Is' type functions and formatters etc..(IsGuid being a favourite in a current project). Other stuff is broken up into more appropriate classes like Security, encryption, compression etc...but I do think these types of classes are necessary.

    One way to get around the problem of these messy source files is through the use of Partial classes like we'll have when Whidbey arrives, these will give a very useful method of breaking the sprwaling source files which can occur when you use this approach into better subdivisions (especially useful when using source control and multiple coders own parts of the same class...not ideal but it does happen!)

  • Scott seems to be interesting the idea of a Common class. Can you develop more ?

  • There realy is nothing to develop...it is literally a catch-all for methods which don't belong anywhere else. These are usually implemented as static methods...with compiled static regular expressions (very useful when validation farily compelx data) implemented within as well.

    It really is better practice not to do this at all - it can lead to some very sloppy practices and you have to keep a tight rein on when something drifts into this class - a rule which I tend to use, is ' is it used by more than 3 unrelated classes' - if they're releated (i.e., can inherit from the same parent class) then the parent class should really implement the method and not the 'Common'.

    If you've got a fair number of methods which are similar (like format validators such as IsGuid / IsLong...etc..) - then by all means set up other classes - oh, and don't be afraid to refactor as you go! Word has it that Whidbey has some pretty neat refactoring stuff!

  • All my pages inherit from a <projectName>Page class, which in turn derives from System.Web.Ui.Page. Pages with more specialized function derive from a subclass of this main page (eg. all the edit pages might derive from <projectName>EditPage). All the convenience methods/objects I need which aren't in the framework are added to the base page(s). I've found creating a base page class to be very powerful (example: I changed all the validators on all of my pages to display a little exclamation mark image beside the control they were validating when there was an error, and show the validation message as a popup when you clicked on the image, all in 4 lines in the base class). I'm fairly happy with it, but would be interested in hearing how others do things.

  • Hi...

    I am have the same question as Mr.Pete. I want to know if he got the solution and would let me know what it is.

    Thank You,

    Yahya

Comments have been disabled for this content.