How to design an ASP.NET app

  • Thread starter Thread starter MattC
  • Start date Start date
M

MattC

I'm designing a simple timesheet system, I have done ASP sites before but
the bulk of my work is in VC++ systems.

I have have started with a list of classes that represent business objects
within the application. However, as persisiting these objects is
performance expensive in the ASP.NET model. What would be too large to
place in the Cache, I was thinking of putting all of the current users
details, username, department, etc.

Am I right in assuming that the Cache is a per-user resource?

Also previously I have created a standard class that control access to the
database. Then if any of my business logic classes require the DB they
simply use this class. Is this paradigm applicable in an ASP.NET app?

Any advice would be welcome.

MattC
 
Hi MattC,

The word "Cache" is a generic term for any memory storage device, including
RAM, HD, etc. So, there is no such thing as "the Cache" in any .Net
application. There are several caching mechanisms which you can leverage for
in-memory caching, including the Application Cache, which is global to the
entire application, and to all users. There is also Session State. Session
State is a cache which is user/Session-specific. In addition, you can use
Cookies, which are text files stored on the client machine, and require no
server memory, for user-specific data that can persist beyond the current
Session, and last for as long as you wish. Cookies cannot store a very large
amount of data, and pose some security risk (don't store sensitive data in
Cookies, which can be read by any text editor on the client machine). On a
per-page basis, you can persist data across PostBacks by using ViewState,
which literally writes serializable data into a hidden form field on the
HTML document sent to the client, and reads it when the page Posts Back.

If you use Session State for caching, be careful of how much data you store
there, as there is a separate Session memory space for every concurrent
user.

And, of course, there is the good old method of storing data in a database,
which is not as fast as memory, but can hold a heck of a lot of data for as
long as you like.

--
HTH,
Kevin Spencer
..Net Developer
Microsoft MVP
Big things are made up
of lots of little things.
 
Ash,

Thanks, I notice from this that the data access for an object is placed
inside the object. From what I've seen elsewhere this is placed in a helper
class that simply contains methods for producing objects that are filled
with information from the database. I know that placing all related
behaviour to do with a class is stricter OOP.

Is either way acceptable?

MattC
 
Back
Top