>>Jim,
>>
>>Glad you brought up this issue of statefulness. Rick Strahl has an article on this on his Web Site. However, I need to take a look at some more detailed white papers. Do you know of any?
>>
>>At first glance, stateless objects look like a real PIA to implement.
>
>Jeff,
>
>Stateless objects aren't the pits, it is the way we think about data that causes the problem. For example we seem to always think about table navigation, next previous and stuff like that. Well in a stateless world you can't do that because the middle tier has no idea or reference to where you were the last time you called. Things have to be done through passing a parameter that tells the middle tier object what to laod and where to point..
>


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. :-)