Question:
When implementing the Microsoft DNA model, it is suggested to create objects with methods only (no properties) to maintain true stateless objects. If an object will only live for the life an ASP page (i.e., not across multiple round-trips to brower and back), why are method calls that much better than using properties? And what are the potential (future) pitfalls for using properties (i.e., plans that Microsoft may have that are strictly based on the pure “stateless” model)?

Answer:
Using stateless components is a tradeoff. With stateful components, there are hundreds or thousands of mini-messages sent over the network when you make calls. Stateless components wrap those mini-messages up into a much smaller number of mega-messages, thus cutting down on network traffic. This is important even on a LAN when you have many users, but it is even more important on a WAN or on the Internet.However, the tradeoff is that the code and interfaces is much less clear and much less object-oriented. Methods tend to have a large number of parameters, which is not ideal either. And you must explicitly create persistance in a different place that where it would make the most sense (ie, the class where the data needs to persisted). You may persist the data at the UI, or in specially designated objects in the business services layer (a component does not *have* to be stateless to run under MTS).