Webforms, Objects, and Basic Architecture

MadGerbil posted on Saturday, June 03, 2006

Greetings:

I've been using business objects now with great success for 4 years but all of the development has been for desktop applications.  Now I've been sucked into designing an enterprise level ASP.NET 2.0 webform and I not only have to pick up ASP.NET 2.0 but I want to use proper architecture and objects to handle the data collection and transactions.

We expect the form to be used 20-30 thousand times a year.

I know the web is a disconnected environment so I'm having a hard time getting my noggin around  how this will work.  What I want is when the user starts up an application I want an object to be created on the server the collects information and provides object status data as the user navigates through several forms.

Is this possible?  Is it difficult?  Can someone describe how this works and the basic architectual decisions that govern this sort of thing?

DancesWithBamboo replied on Monday, June 05, 2006

I see there haven't been any replies yet and its been a while.  This could be because you basically asked "How to design a web application".  You might need to focus your question a bit more. 

CSLA certainly works very well in a web environment and I have been using it for a long time to build web apps.  The question you pose is really how to manage state in a disconnected web world.  The answer comes down to to a balance of object size, load, response time, and money.  It is possible to keep all of the objects alive on the server in the session state for each user.  This provides for fast access if your user community and load is small or if you have a lot of money and can by many servers with lots of RAM(and dedicated session state server).  Or you can refetch and recreate objects from the database as the user switches pages.  This is great if you have a massive user load or not a whole lot of money.  Or you can do something in between with some small objects staying persistant in the session for each user while other larger objects are recreated.

You gave me the impression that you may have some sort of a data entry "wizard" of sort where each successive screen the user enters more data.  One way to build this sort of thing (assuming your user community has acceptable machines with resonable bandwidth) is to use the ViewState in connection with the HttpContext.  Basically you send the object to the client in the Viewstate on the initial page load and then you get it back when the form is posted.  Then you take your object and put it into the HttpContext and do a Server.Transfer to give it to the next page of the wizard.  Repeat as necessary.

Another option that is a little more advanced that I have used succesfully is to only have one page with the objects needed loaded into the viewstate and then just dynamically load differnet user controls on the page depending on what "tab" of the wizard the user is on.  This way you are always going back and forth to the same page and it is just presenting itself differently each time.  This is nice becuase it allows you to have all of the logic associated with saving and validating on just one form without the need for any inheritance or such.

As you can see, there are always several ways to do the same thing in the web world.  Sometimes you just need a good coin to toss.  You might just find building the business objects to be the easy part!