Idea 2 is mimicking Session state management. I don't see an intrinsic benefit from performing your own session statement management.
cfeduke
2008-10-22 15:06:51
A:
... unless you need to share data between sessions, of course. But generally avoid it unless you have a reason to do it. A good reason.
cfeduke
2008-10-22 15:12:57
A:
Idea one has the benefit of ASP.NET managing the sessions for you. I could see the second option becoming problematic if you have users that don't complete the full lifecycle as then you have entries in the hash table that reference old sessions. At minimum if going with #2 I would be building in a cleaning process to ensure that old sessions are expiring.
If you just need to hold current step information, I'd almost vote for session as there is no point trying to re-invent it.
Mitchel Sellers
2008-10-22 15:09:04
Interesting point, in this scenario, I have a guarantee that I can manage when a user logs off, or when the transactions are complete.
mmattax
2008-10-22 15:13:06
If you are 100% sure on that then I don't see a problem with #2, but I would be REALLY sure that you have this...what if the client looses network connection partway through?
Mitchel Sellers
2008-10-22 15:18:32
+1
A:
You should take a look at Windows Workflow Foundation (WF). You can design your workflow, then plug in persistence models and such.
That being said - you can't use the session! it won't scale once you create multiple web farms/servers. Surely the QBW developer API needs to scale and be fault tolerant!
Some more info about using this with ASP.NET is here.
TheSoftwareJedi
2008-10-22 15:12:23
I have to keep the web service scheme- I am writing an integration piece for the QuickBooks Web Connector, which requires SOAP services.
mmattax
2008-10-22 15:17:45
You can keep the web service scheme, but use WF for it's state and persistence.Some interesting info here about using WF in ASP.NET: http://www.devx.com/dotnet/Article/29992/1954
TheSoftwareJedi
2008-10-22 16:29:47
+1
A:
This might be one of those situations where you are already too far to do a large refactor, but ...
Sounds identical to a state workflow in Windows Workflow. If your plan is eventually expose each of those methods as their own encapsulated services, it would give you all that state management for free, plus you get the added benefit of being able to visually define the workflow between these service calls.
http://msdn.microsoft.com/en-us/magazine/cc163538.aspx
[EDIT]: Shoot, Jedi beat me to it. What he said.
joshua.ewer
2008-10-22 15:12:31