Read this in the thread regarding petshop example using llblgenpro. Jeffreygg says

. By implementing both stateful and stateless properties in you manager classes, you can manage both process and business logic in one place. However, your business logic classes are now very closely bound to your presentation layer.

Great insights Jeff but just trying to understand this and its implications. My first assumption is that stateless means using static/shared methods in the manager classes. If this is correct, then the benefit of using static methods is that it decouples your presentation layer(pl) from the bll, since you don't need to instantiate the manager class with stateful methods(none static) in the pl. Thus, you are pretty much free to implement any kind of pl you want, web, windows, etc). Is this a correct assumption as to why use static methods for manager classes? If so, what are the disadvantages to doing this?

Lastly, why is using static methods considered stateless? Newbie here so forgive me for the stupid question.

erichar11 wrote:

Read this in the thread regarding petshop example using llblgenpro. Jeffreygg says

. By implementing both stateful and stateless properties in you manager classes, you can manage both process and business logic in one place. However, your business logic classes are now very closely bound to your presentation layer.

Great insights Jeff but just trying to understand this and its implications. My first assumption is that stateless means using static/shared methods in the manager classes. If this is correct, then the benefit of using static methods is that it decouples your presentation layer(pl) from the bll, since you don't need to instantiate the manager class with stateful methods(none static) in the pl. Thus, you are pretty much free to implement any kind of pl you want, web, windows, etc). Is this a correct assumption as to why use static methods for manager classes? If so, what are the disadvantages to doing this?

I'm not entirely sure I follow you, but imagine the business layer as a service that takes in "bundles" of "completed" logic. You don't want the business layer to assist in walking the user through creating these bundles as that would violate the "one class, one responsibility" tenet of OO programming. Thus emerges the concept of a stateful class that provides all of the presentation layer logic or "process", and another, separate, stateless class that manages the business logic (although there is no law that says your BLL class must be stateless, developing it this way paves the way for a solid remoting or SO architecture)

The more you merge these two functions into one class, the more that class is tightly coupled to the presentation layer you're currently developing against as it is that presentation layer's flow that dictates how the stateful members are created. The business layer's stateless methods aren't constructed to help the user/presentation layer walk through the process; they're there to take in the final result and validate or initiate action based on it.

Lastly, why is using static methods considered stateless? Newbie here so forgive me for the stupid question.

When talking in terms of OO, we're speaking of stateless or stateful objects. You're right in that a shared/static method can maintain it's state across calls, but typically if your class contains all shared/static members, as might be the case in your BLL, then there are no internal fields, the class is never instantiated into an object and thus it can never track internal state.

The more you avoid treating your BLL like a helper through a specific process, the better, IMHO, as the process itself can be implemented differently depending on the presentation method used.

Think about the implications of building a complete desktop app then getting a new requirement to implement one of those processes on the PocketPC. If you're BL is really business logic wrapped up into helper functions for the desktop GUI, you're going to be bummed when you try to use it in a CF context.

Hope that helps.

Jeff...