Maya, You mentioned that you are providing access to things in the users database. Are you giving them write access? If not there is little reason to use Entity Beans (read None) in your application. If you don't need your application to be distributed, and I didn't see it in your requirements, then session beans may be overkill too. I would look to what others have said here and evaluate hibernate or naked JDBC before choosing entity beans as your backend and session beans as your business facade. (though I wouldn't write off session beans entirely). Using something like a command pattern could work nicely as a business facade. I am working right now with an application that uses a command pattern for the business layer and I am quite fond of it. You could also have a look at the Commons-Chain project for a nice implementation of a pattern that is quickly becoming one of my favorites. http://jakarta.apache.org/commons/chain And beginning with struts 1.3 it will be a first class citizen of Struts.
Michael On 7/20/05, Leon Rosenberg <[EMAIL PROTECTED]> wrote: > > > > -----Ursprüngliche Nachricht----- > > Von: Dave Newton [mailto:[EMAIL PROTECTED] > > Gesendet: Mittwoch, 20. Juli 2005 22:20 > > An: Struts Users Mailing List > > Betreff: Re: Hi-New to this group > > > > [EMAIL PROTECTED] wrote: > > > > >I don't understand Dave's concern. Perhaps he would > > elaborate on why he says to avoid Session beans. > > > > > > > > Anything EJB-related I've run in to (except in a few > > instances) has been mind-blowing overkill, that's all. > > > Session Beans are absolute performance killers, and a huge ressource eater. > > And I think the proper question is not "why to avoid session beans" but > "why use session beans in this application". > > I think it's the question you should answer, and you should review the usage > of every piece > of third party software. If you can't answer the question "why do i use this > framework/lib/software" you probably shouldn't use it. > > Regards > Leon > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
