Best Practices Question - Where do I put common code?

[wrecker]

Hi all,

I have a few common methods that I need to use at different points in
my web application. I'm wondering where the best place would be to
put these? I think that I have three options.

1. I can create a common module like common.vb in my project and put
all the functions in there.

2. Create a utility class and create the common functions as shared
methods

3. Create a page base class that contains the common methods and then
inherit all my pages from that base class.

What's the accepted way to make a method available to all pages in an
application?

Thanks

Ren

[Rakesh Rajan]

Hi,

If these methods are part of a page in a logical sense, then I would define
a BasePage class which will have these methods.

On the other hand, if these are generic (meaning not related to Pages), then
I would create a seperate project (or a common class) which will host this
utility class which will have static (shared) methods (only shared methods -
no shared class fields though).

I usually create a separate project for hosting common classes because as
the project moves forward, I will always have many common things which I
place in this assembly.

Personall, I would stay away from modules - I feel that is too VB specific.

--
HTH,
Rakesh Rajan
MVP, MCSD
http://www.rakeshrajan.com/
"wrecker" wrote:

Hi all,

I have a few common methods that I need to use at different points in
my web application. I'm wondering where the best place would be to
put these? I think that I have three options.

1. I can create a common module like common.vb in my project and put
all the functions in there.

2. Create a utility class and create the common functions as shared
methods

3. Create a page base class that contains the common methods and then
inherit all my pages from that base class.

What's the accepted way to make a method available to all pages in an
application?

Thanks

Ren

[Kevin Spencer]

> 1. I can create a common module like common.vb in my project and put

all the functions in there.
Modules are bad, m'kay? Everything in a Module is static (Shared) and not
only globally available, but not ThreadSafe. Modules are lip-service to VB6
developers, but ASP.Net is not VB6, as much as it looks like it.
2. Create a utility class and create the common functions as shared
methods
A much better idea. However, again, you should use caution with static
(Shared) methods and properties. Encapsulation is a beautiful thing, and
while it is certainly appropriate to create static methods and properties,
there are situations where it is most certainly NOT. For example, creating a
static method that is simply a process that takes parameters and uses
function-scoped variables is an excellent way to re-use code. But a static
Collection is going to bite you in the arse eventually. As it is not
ThreadSafe, and ASP.Net is multi-threaded, you may have more than one
process trying to do more than one thing with the Collection at a time. One
process might be removing an item from the Collection while another is
iterating through it. OOPs. The same goes for static methods that operate on
static fields or properties that are scoped outside of those methods.

So, yes, use it, but no, don't abuse it. Be aware of the issues, and work
with them.
3. Create a page base class that contains the common methods and then
inherit all my pages from that base class.
Inheritance is a wonderful thing. Here's where we start thinking seriously
about Architecture. For example, would any of the common methods come in
handy in another app? You might want to put them into a business class that
the inherited Page makes use of, rather than defining them in the Page class
itself. You may see a use for more than one layer of inheritance as well.
This depends on your present requirements, taking possible future projects
into consideration at the same time. How much of this functionality will you
always want to inherit? How much will be optional? What sort of
functionality or methodology would you expect to share between this and
future projects? If you take your time and think these sorts of questions
through, you should be able to come up with a solid extensible model to go
by.
What's the accepted way to make a method available to all pages in an
application?
It all depends on what the method is, what the requirements of the
application are, and how the design and placement of the method will affect
future development. There is no single one-size-fits-all correct way to do
this. The above information should provide you with some of the
considerations that you should take into account in the process of making
this decision.

A solid understanding of the "pillars" of OOP, abstraction, inheritance,
encapsulation, and polymorphism, will help you immensely in your design
process.

Your questions show a good degree of thoughtfulness. This implies (to me at
least) that you will probably do well in your design efforst.

--
HTH,

Kevin Spencer
Microsoft MVP
..Net Developer
Ambiguity has a certain quality to it.

<wrecker> wrote in message
news:kn********************************@4ax.com... Hi all,

I have a few common methods that I need to use at different points in
my web application. I'm wondering where the best place would be to
put these? I think that I have three options.

1. I can create a common module like common.vb in my project and put
all the functions in there.

2. Create a utility class and create the common functions as shared
methods

3. Create a page base class that contains the common methods and then
inherit all my pages from that base class.

What's the accepted way to make a method available to all pages in an
application?

Thanks

Ren

[Rakesh Rajan]

Hi,

Just in case you want to know more about statics and threads, check out the
two part series Scott has written.
http://odetocode.com/Articles/313.aspx

--
HTH,
Rakesh Rajan
MVP, MCSD
http://www.rakeshrajan.com/
"wrecker" wrote:

Hi all,

I have a few common methods that I need to use at different points in
my web application. I'm wondering where the best place would be to
put these? I think that I have three options.

1. I can create a common module like common.vb in my project and put
all the functions in there.

2. Create a utility class and create the common functions as shared
methods

3. Create a page base class that contains the common methods and then
inherit all my pages from that base class.

What's the accepted way to make a method available to all pages in an
application?

Thanks

Ren

[Damien]

Kevin Spencer wrote:

1. I can create a common module like common.vb in my project and put
all the functions in there.

Modules are bad, m'kay? Everything in a Module is static (Shared) and not
only globally available, but not ThreadSafe. Modules are lip-service to VB6
developers, but ASP.Net is not VB6, as much as it looks like it.

2. Create a utility class and create the common functions as shared
methods

A much better idea. However, again, you should use caution with static
(Shared) methods and properties. Encapsulation is a beautiful thing, and
while it is certainly appropriate to create static methods and properties,
there are situations where it is most certainly NOT. For example, creating a
static method that is simply a process that takes parameters and uses
function-scoped variables is an excellent way to re-use code. But a static
Collection is going to bite you in the arse eventually. As it is not
ThreadSafe, and ASP.Net is multi-threaded, you may have more than one
process trying to do more than one thing with the Collection at a time. One
process might be removing an item from the Collection while another is
iterating through it. OOPs. The same goes for static methods that operate on
static fields or properties that are scoped outside of those methods.

So, yes, use it, but no, don't abuse it. Be aware of the issues, and work
with them.

3. Create a page base class that contains the common methods and then
inherit all my pages from that base class.

Inheritance is a wonderful thing. Here's where we start thinking seriously
about Architecture. For example, would any of the common methods come in
handy in another app? You might want to put them into a business class that
the inherited Page makes use of, rather than defining them in the Page class
itself. You may see a use for more than one layer of inheritance as well.
This depends on your present requirements, taking possible future projects
into consideration at the same time. How much of this functionality will you
always want to inherit? How much will be optional? What sort of
functionality or methodology would you expect to share between this and
future projects? If you take your time and think these sorts of questions
through, you should be able to come up with a solid extensible model to go
by.

Just to add here:

You may find that some functionality naturally lives within a page,
especially if you need access to the HttpContext (e.g. Page, Request,
Response, Session), but for more general purpose functionality, I would
tend to place that in seperate utility classes/projects (depending upon
how likely it is to be reused in seperate solutions).

Some examples:
Image manipulation functions - seperate project. Gonna be reusable in
different situations, even non-ASP.Net solutions.

Password Management and Client Logon - seperate class. Specific to the
authentication mechanism being used.

Navigation checks (ensuring valid navigations are occuring) - Base
Class, since we need access to the Request and the Session.

Damien

[snip rest]

[JIMCO Software]

Kevin Spencer wrote:

1. I can create a common module like common.vb in my project and put
all the functions in there.

Modules are bad, m'kay? Everything in a Module is static (Shared) and
not only globally available, but not ThreadSafe. Modules are
lip-service to VB6 developers, but ASP.Net is not VB6, as much as it
looks like it.

That's a good point that many people overlook. If you're going to use
Shared objects in VB.NET, you should use the Monitor class to control access
to them. In C#, you use the lock keyword.

--
Jim Cheshire
JIMCO Software
http://www.jimcosoftware.com

FrontPage add-ins for FrontPage 2000 - 2003