views:

164

answers:

2

We have a large WebForms application here that we would like to port over to mvc piece by piece.

I'd rather not have a co-mvc/webforms solution but would rather create a brand new mvc application which can be called from our webform application and which can call our webform application.

the problem lies in sharing information between the two. we use the session object quite heavily in the webforms application and this, until everything is converted, needs to stay the same.

so is there a way for us to write to the session object in our mvc application and have the webforms application pick it up and vice-versa?

or can anyone suggest another, non database, way to do this?

edit

Actually I'll extend this to be "share across web applications".

+2  A: 

Please excuse me for not answering the question directly but can I give you some advice?

Any advantage that you may possibly get from converting a "large WebForms application" where you use "the session object quite heavily" to an MVC app will be swamped by the costs of rewriting the application.

It won't even be close.

A few years back, an acquaintence of mine who owned a $1-2 million/year company in the health field let his engineers talk him into a rewrite of their flagship product. Their motivation was that they had heard just how wonderful one of Microsoft's new technologies was going to be (VB6 if you need to know - the original tech was Delphi).

The company was out of business inside of two years.

Not only was the product late, it had fewer features and more bugs than the old product. Their competition? Well, while they were feeling all smug and "latest tech" during their rewrite, the competition was adding features and improving their products. The market's judgement was swift and brutal: it doesn't care if you feel good about your shiny, new technology.

With respect to MVC and WebForms in general, I am quite well-versed in both and I do like MVC. But they are simply two different ways of getting to the same point and each has its advantages and disadvantages. The idea of rewriting an app on which your business depends just to go from one to the other sounds crazy to me.

Mark Brittingham
Your comment is completely valid but we are in the process of re-writing a large section of the existing WebForms site and have already replaced another section of it. We are also going to farm the remainder of it out to SharePoint. So yeah, we're not re-writing just for the heck of it. There are some very valid reasons for the switch. +1 for your answer because it is valid.
griegs
griegs - thanks for the upvote. Good luck!
Mark Brittingham
Yeah thanks. We think we may have it. We only really need to send over 7 properties so we'll make an object, serialise it and shoo it over. Seems the simplest.
griegs
+1  A: 

This article http://www.asp101.com/articles/jayram/sharestate/default.asp suggests using one web application with each website as subfolders (not web applications) underneath, but this seems a bit clunky to me.

A better option is to use a shared session store outside of the web application process. The obvious choice is the SQL State Service but if you don't want a database you could roll your own session provider.

If you're only sharing a small number of simple objects you could copy them via form posts or query string. Use the file system instead of a database? Obviously you would have to synchronise objects from both websites, depending on your requirements.

AUSteve