How Can I Define Global Classes In Web Application ?

[Sylvia A.]

How can I define global classes in web application ?

Classes can be set to session variables ?

Thanks

 

[Prakash V]

Create your class in App_Code folder, you can store any objects in session.

Regards
Prakash.V

 

[Juan T. Llibre]

rea:

How can I define global classes in web application ?

1. You can place source code in the App_Code directory.
Any source files you place there will be compiled.

2. You can compile them yourself and place the generated
assembly/assemblies in the /bin directory.

That protects your source code a bit more.

To compile a single source code file, use :

csc /t:library /out:utils.dll utils.cs

To compile all .cs files in a directory to utils.dll ,
use : csc /t:library /out:utils.dll *.cs

If you need to reference a .Net Framework assembly or assemblies,
add them, separated by slashes :

csc /t:library /r:system.dll /r:system.data.dll /out:utils.dll *.cs

If you're using VB.NET instead of C#,
use vbc and source files ending in .vb
instead of using csc and source files ending in .cs.

The syntax is the same for vb and c#.

Once you have compiled your assembly, place it in the /bin
directory of your application, and import the Namespace :

<%@ Import Namespace="YourNamespace" %>

If you're working strictly with VS.NET, compile your assembly
as described and add a reference to it in your VS.NET project.

That will allow you to use Intellisense and get your
assembly's properties, methods, etc. when coding.

re:

Classes can be set to session variables ?

If you mean to use classes to *set* session variables, yes.

How can I define global classes in web application ?

 

[carion1]

Storing ref types in Session isn't advisable but here you go.

//create it
myObject myObjectInstance = new myObject();

....do work here...

//dump it into session
Session["myObject"] = myObjectInstance;

//pull it back out of session
myObject myObjectInstance = (myObject)Session["myObject"];

I would store the information needed to re-produce the object and it's
state rather than store the object in Session.

 

[Juan T. Llibre]

Storing objects in another object (especially in the session object) is *always* a Bad Idea.

Storing ref types in Session isn't advisable but here you go.

//create it
myObject myObjectInstance = new myObject();

...do work here...

//dump it into session
Session["myObject"] = myObjectInstance;

//pull it back out of session
myObject myObjectInstance = (myObject)Session["myObject"];

I would store the information needed to re-produce the object and it's
state rather than store the object in Session.

How can I define global classes in web application ?

Classes can be set to session variables ?

Thanks

 

[Kevin Spencer]

Your question is somewhat confusing, which may explain the variety of
replies you've received. Let me ask you a few questions first:

Define "Global."

"Global" is a relative term, which refers to scope. For example, to a baby,
"Global Scope" might mean the entire house which is the "world" the baby has
experienced. However, the house is in a neighborhood, so at a slightly
greater age, the child might think of "the world" as their neighborhood.
Since the neighborhood is in a city, the Mayor of the city might think that
"City-wide" is the definition of "Global." The state Governor might think in
terms of the state he/she governs, or even the entire country (all states
together). The president would probably think of the entire world. Or
perhaps, one might think of the Milky Way galaxy as "Global" scope. Or, the
entire universe. So, "Global" must be defined in order to discuss it.

In an application, in the strictest sense of the word, "Global" means
"Application Scope," that is, available everywhere in your web application.
This is entirely different than "Session Scope" which is restricted to those
pages being viewed by a single client in a single browser Session, and also
includes a region of memory in the Application devoted to storing Session
data (the HttpSession class). Still, Session scope can sometimes be termed
"Global," as long as it is understood that the context is Session-wide. In
fact, the term "Global may mean "Global within a class," as in a Page
instance, or "Global within an Assembly" if one is talking about the
Assembly in which a class resides. It's all defined by context.

So, when you entitle your message with the word "Global" and don't define
it, and then add a question about "Session," it muddies the water. What
exactly do you want to limit your scope to? What is the requirement you are
trying to fulfill?

--
HTH,

Kevin Spencer
Microsoft MVP

Printing Components, Email Components,
FTP Client Classes, Enhanced Data Controls, much more.
DSI PrintManager, Miradyne Component Libraries:
http://www.miradyne.net

 

[Sylvia A.]

I created a class, for example UserClass, It holds the information about the
logged user, such as, ID, Name, Address, Limits, etc.. Whatever column I
need

This class is created and filled when a specifific page is loaded, such as
login form, after pressing Login button,

After some time in the session, when I go other aspx pages, I wanna get
class info, no need to recreate and fill class from DB,

Such things..

Thanks

 

[=?ISO-8859-1?Q?G=F6ran_Andersson?=]

I am a little curious about your statement. Why do you say so?

As objects is the only thing that you *can* store in the Session object,
it would mean that storing anything there would always be a bad idea.

Storing objects in another object (especially in the session object) is *always* a Bad Idea.

Storing ref types in Session isn't advisable but here you go.

//create it
myObject myObjectInstance = new myObject();

...do work here...

//dump it into session
Session["myObject"] = myObjectInstance;

//pull it back out of session
myObject myObjectInstance = (myObject)Session["myObject"];

I would store the information needed to re-produce the object and it's
state rather than store the object in Session.

How can I define global classes in web application ?

Classes can be set to session variables ?

Thanks

 

[Juan T. Llibre]

re:

As objects is the only thing that you *can* store in the Session object,

Really ? You mean that plain text can't be stored in the Session object ?

Even if some data *looks* like an object, like MyClass.MyParam.Value,
that's *still* string or numeric data stored in it, so you're not storing the object.

You're storing string/numeric *data*.

re:

it would mean that storing anything there would always be a bad idea

No. Only storing *objects* in the Session object is a bad idea.

String/numeric data is easy to store in the session object and has minimal
impact on system performance, unless they are massive in volume.

You can also store *objects* in the Session Object, besides string/numeric data.
Datasets, arrays and datatables are examples of objects.

However, storing objects in session variables can have a serious performance impact.

If a dataset, for example, is a 500Kb object stored in session, when there's 1,000 users
accessing your session object within the time specified for session timeout, you'll have
a 500MB RAM drain on your server. That's not good.

There's other considerations, too. To be able to *use* the objects,
you'll need to serialize/deserialize them. That takes additional cpu cycles.

For an object like a datatables, they're already marked as serializable.
For custom objects, you'd have to make sure they're serializable.

Using the Cache to store data is much more efficient than storing objects in the Session object.

I am a little curious about your statement. Why do you say so?

As objects is the only thing that you *can* store in the Session object, it would mean that
storing anything there would always be a bad idea.

Storing objects in another object (especially in the session object) is *always* a Bad Idea.

Storing ref types in Session isn't advisable but here you go.

//create it
myObject myObjectInstance = new myObject();

...do work here...

//dump it into session
Session["myObject"] = myObjectInstance;

//pull it back out of session
myObject myObjectInstance = (myObject)Session["myObject"];

I would store the information needed to re-produce the object and it's
state rather than store the object in Session.

How can I define global classes in web application ?

Classes can be set to session variables ?

Thanks

 

[Mark Rae]

For an object like a datatables, they're already marked as serializable.
For custom objects, you'd have to make sure they're serializable.

Using the Cache to store data is much more efficient than storing objects
in the Session object.

Yes, I would agree with that.

For objects which are unique per Session, especially if they are highly
*unlikely* to change for the duration of the Session (e.g. a user profile
etc) I use the Cache. I tend to use the Session object only for tiny
snippets of data which have a very short lifespan e.g. maybe for persisting
data between pages where I don't want to use a QueryString etc...

Since we're on the subject, I'm interested to know your opinion on using the
Application object for persisting data which is always the same for every
user and which *almost* never changes, maybe for years and years... I'm
thinking specifically of country and currency (not exchange rate) data in a
very heavily used international order processing system. Rather than
fetching this data maybe thousands of times a minute every time a user gets
to the checkout page, would you consider it sensible to store it as DataSets
in the Application object e.g.

cmbCountries.DataSource = (DataSet)Application["Countries"];

 

[Juan T. Llibre]

re:
!> your opinion on using the Application object for persisting data which is always
!> the same for every user and which *almost* never changes, maybe for years and years.

The Application object is a good place to store data of that type.

The economies of scale inherent in using the Application object, as opposed to
using the Session object, are considerable when dealing with seldom-varying data.

The only caveat is whether the method employed to update the data,
when an update *is* made, can be automated.

A good way to insure that would be to use a Cache and/or SqlCache dependency.
You can cache application data based on database dependencies.

Our good friend, Peter Bromberg, explains how to do this in this article :
http://www.eggheadcafe.com/articles/20060407.asp

Yes, I would agree with that.

For objects which are unique per Session, especially if they are highly *unlikely* to change for
the duration of the Session (e.g. a user profile etc) I use the Cache. I tend to use the Session
object only for tiny snippets of data which have a very short lifespan e.g. maybe for persisting
data between pages where I don't want to use a QueryString etc...

Since we're on the subject, I'm interested to know your opinion on using the Application object
for persisting data which is always the same for every user and which *almost* never changes,
maybe for years and years... I'm thinking specifically of country and currency (not exchange rate)
data in a very heavily used international order processing system. Rather than fetching this data
maybe thousands of times a minute every time a user gets to the checkout page, would you consider
it sensible to store it as DataSets in the Application object e.g.

cmbCountries.DataSource = (DataSet)Application["Countries"];

 

[Mark Rae]

re:
!> your opinion on using the Application object for persisting data which
is always
!> the same for every user and which *almost* never changes, maybe for
years and years.

The Application object is a good place to store data of that type.

The economies of scale inherent in using the Application object, as
opposed to
using the Session object, are considerable when dealing with
seldom-varying data.
Understood.

The only caveat is whether the method employed to update the data,
when an update *is* made, can be automated.

A good way to insure that would be to use a Cache and/or SqlCache
dependency.
You can cache application data based on database dependencies.

Our good friend, Peter Bromberg, explains how to do this in this article :
http://www.eggheadcafe.com/articles/20060407.asp

Indeed - always good to learn from the master...