Eric,

I completely agree. I'm have just begun thinking about this as my biz objects are currently statefull. I haven't done any web development yet, but will be soon and I need to come up with an approach - hopefully something simple and as efficient as possible.

I just made another reply to Jim and was wondering if a cursor state object would be feasible - an object with state properties and GetState() / SetState() methods.

I don't know - do you know of any detailed white papers on this?



>Just to add, I really believe that all developers need to be looking in to stateless, because things are definitely headed that way. IF you have done any web development at all, then you have had to deal with restoring state on every single call, whether its from a cookie, an IP address, hidden form variable, or whatever. As our systems become more distributed, and interprocess communication is handled more on a messaging basis as opposed to a connection basis, every business process will need to know how to operate statelessly.
>
>If you think about it, stateless objects are the only objects that are perfectly encapsulated. They depend on NOTHING external (not even setup code), only the parameters passed in each method call. Beginning to think stateless will help you design better code that is more transportable, and that can be accessed through any interface. It only looks like a pain in the ass to implement because its a different way of thinking. Instead of setting properties and then calling a method, you pass a few parameters, or a message that the object knows how to decipher (ie XML).
>
>Building objects optimized to run in MTS (it will happily run stateful objects, but the advantages of using MTS in the first place start to dissappear) just forces you to think statelessly. I think that you will find that building an object to run completely statelessly will take little or no more code than the same object being used with property settings and multiple calls. You just have to get into the stateless groove. :-)