Public Sub/vars in web app?

[thdevdex]

I'm new to the web forms world (ASP.Net) but not vb and am converting a
vb6 windows app to the web. If I create public subroutines at a module
level, is this a problem in a server based app? Will my users step on
each other? I'm confused about whether global module level subroutines
and variables are exposed to all users at the same time or if .NET gives
them their own space at runtime.

Also, I'm assuming that creating a class for each subroutine will give
me an instance of the object where it's data is encapsulated thereby
eliminating the above if there is a scope problem. Just looking for
thoughts here.

Thanks.

 

[Chris Jackson]

Everything in ASP.NET is going to be wrapped in a class, and any two objects
that share the same instance of an object of this class will share the same
values in variables. If you want to store information specific to a user,
you should use the Session object. If everyone should share the same piece
of information, then you should use the application object. You also have
several additional mechanisms of storing persistent information, such as
ViewState, Cache, and so forth - it really depends on what your needs are as
to what is the best choice for the problem you are trying to solve.

 

[Kevin Spencer]

You need to understand that while the syntax of VB.Net is similar to VB6,
VB.Net is truly object-oriented, whereas VB6 is not. So you have to start
thinking in object-oriented terms. While VB.Net allows you to create
Modules, this is more for backwards-compatibility than it is useful. Modules
are not truly object-oriented, and you really want to leverage the
object-orientation of the .Net platform as much as possible. And modules,
which are never instantiated, will indeed cause the problems you have
mentioned, as everything in a Module is Shared.

You also don't want to create "a class for each subroutine" - rather than
thinking in terms of subroutines, you need to start thinking in terms of
Methods. A Method can be either a Sub or a Function, but it is a member of a
class. A class can have many Methods encapsulated within it. You want to
organize your classes to contain Methods that share something in common,
whether that is data that is global to the class, or functionality. If you
want to create Methods that don't require instantiation, you can create
Shared Methods. Within a class you can have both Shared Methods (which don't
require an instance of a class - similar to subroutines in a module) and
Methods which require an instance of the class. You need to determine which
kind of Methods to create in the class, according to the functionality and
requirements of the Methods.

Learning to leverage the full object-orientation of .Net is a learning
curve, but will empower you in ways you probably haven't yet imagined. Try
to get familiar with concepts of encapsulation, polymorphism, and
inheritance in particular. And familiarize yourself with the various kinds
of additional scope that object-orientation affords. The Microsoft .Net SKD
is a free download from:

http://www.microsoft.com/downloads/...A6-3647-4070-9F41-A333C6B9181D&displaylang=en

--
HTH,

Kevin Spencer
Microsoft MVP
..Net Developer
http://www.takempis.com
Neither a follower nor a lender be.