Perhaps the term "business logic" is misleading to an extent. To some, business logic in JavaBeans can mean that a JavaBean is a stateful representation of data in a database, that also has 'logic' in it for other means, such as validation, computation, etc. The term used like you suggest would fit in a model like stateless session beans, although something could be developed that isn't EJB. Now you mention a lookup/mapping mechanism, well look at Avalon (http://jakarta.apache.org/avalon). It has just such a mechanism.
I believe in using both approaches, using beans as data and logic as well as stateless logic components. We use both for our eQ! product and (slowly) I'm convincing others that we should build it upon Avalon. Our Struts adapters and our scripting engine (both of which I wrote) use Avalon for looking up other components. I'm trying to convince the boss to let me port our persistence layer to use the same framework. - Robert -----Original Message----- From: Daniel Steinberg [mailto:[EMAIL PROTECTED]] Sent: Wednesday, February 20, 2002 12:06 PM To: '[EMAIL PROTECTED]' Subject: Business logic "beans" The Struts User's Guide suggests that business logic be encapsulated in beans. Business logic modules are generally stateless, so one would generally implement them as static utility classes (with only static methods) or singletons (with private constructors and static factory methods), neither of which can be "beans" (which, by definition, have public constructors). To effectively manage stateless classes as beans (without re-instantiating them for each use), one would have to implement a lookup/mapping mechanism (an "EJB-lite"). Are the Struts developers suggesting that we develop such mechansisms? Might such a mechanism be slated for a future version of Struts? -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>