Moving a session based asp.net application to an n-tiered architecture

I've inherited a large asp.net website that relies heavily on session information.

There is a back-end system that feeds it necessary information as needed through web services, but the application itself has no database, and everything is kept in session through a bunch of Data Objects which are accessed directly throughout the entire application.

I eventually want to try to migrate the application to a true N-Tier architecture, and start using a database instead of session based data objects.

My question is, what is a recommended path to get to the desired architecture?

I'm thinking that an initial step would be to create a Data Access Layer for accessing the data objects. Once this is in place, I would then be able to replace the data objects with a database.

The problem is that the session Data Objects are directly accessed from everywhere in the application. Because these objects are stored in session, you can directly set any of their properties without anything controlling the data. This is done throughout the whole application.

For example, say you have a customer Data Object stored in session. If you wanted to modify this customer, all you have to do is to set a local variable to the object stored in session. You could then update anything in the object just by setting mylocalvar.LastName = "blah"; Your session object is now updated without doing anything else.

Has anyone done anything like this before, and has any ideas on steps I could use to accomplish it?

*note: I'm not looking to off-load the session data, but to re-architect how the data is saved and accessed.

+1 My thoughts exactly - abstract it out; and whe you do, keep the Interface Segregation Principle in mind.

Adrian K 2010-07-21 01:51:55

Yeah, it's going to be tricky for sure. What you laid out is the basic direction I was thinking of going. The biggest problem is that there aren't any standard data manipulation mechanisms in place, such as explicitly saving the data, transactions, etc. The application just sets a local (usually global) variable to an already existing object from session, and then directly updates it's properties as needed. Are you aware of any tricks that would help move from one design to the other?

AaronS 2010-07-21 03:36:33

So at what point does the local/global variables get stored back into the session state after being manipulated? At that point, i'm guessing, would be where you'd do a "save" of the data in your new abstraction layer.

Frank Tzanabetis 2010-07-21 04:41:54

Unfortunately, That's the problem. All you have to do is modify any property on the object and the session object is automatically updated. You don't need to do anything else. Take a look at the customer example in my original post. It shows how the data is manipulated.

AaronS 2010-07-21 12:44:48

Doesn't sound like there's an easy way around that based on what you've described; I can't think of any suggestions apart from my original answer anyway. Committing to the database every time the gui sets a property doesn't really sound like a good idea, so i suppose that means going through all the code to pull all the data/business logic out of there. Sounds almost like a rewrite.

Frank Tzanabetis 2010-07-22 00:57:21

ansaurus

tags:

views:

answers:

Moving a session based asp.net application to an n-tiered architecture

related questions