Personally, I am not a big follower of EJB and I echo the sentiments that EJBs are a performance killers. My own experience with Entity Beans has not been pretty good.
So until you have some very strong reasons to go for EJB, dont! In my limited knowledge , Spring with Hibernate or Ibatis, is a good substitute for EJB, if you want EJB features, without paying for the expense of remote look up, or you can use EJB with local interfaces (I believe that using local instead of remote removes a big performance overhead). Thanks and Regards, Nitish Kumar -----Original Message----- From: Michael Rasmussen [mailto:[EMAIL PROTECTED] Sent: Thursday, July 21, 2005 2:50 AM To: Maya menon; Struts Users Mailing List Subject: Re: Hi-New to this group Maya, See inline On 7/20/05, Maya menon <[EMAIL PROTECTED]> wrote: > Michael, > > Yes: in our web app, in the jsp, there will be a button/checkbox which the > users can click to let the system know about the status of their work. Now, > when they click it, it can directly update the database. [rather than that, > i dont know..] > > I was not thinking about using entity beans at all. I was thinking about > using session beans as facade and all database activities being performed > inside DAOs [select,update etc] That is probably wise. Hibernate (http://hibernate.org) which was mentioned earlier is a good mix of POJO and persistence framework, but for 500 users you are probably small enough that DAO/JDBC will be fine. Especially if you don't need any transactional support. > > You talked about command pattern. where will a command patterm come when > used with struts ? sorry, i dont know hence i asked. > For an explanation of the command pattern see the GOF Command Pattern or here http://www.dofactory.com/Patterns/PatternCommand.aspx, (first result in Google) Basically your action would delegate to the command and pass it a context (Populated by your form data). All the commands implement the command interface (with the execute(Context) method). The command could then delegate to other worker commands that do database work or send emails or other generic tasks. Then the action works like all actions do and takes what is in the context and puts it in the right scope and forwards on to the JSP. The commands can be broken up (similar to session beans) to do small units of work. If you use a factory to get your commands the factory can be configured to return different instances of the command based on user roles and so on. > Struts action classes -> ? -> ? - DAO. > Struts action classes -> command -> command - DAO. Michael > Thanks > > Michael Rasmussen <[EMAIL PROTECTED]> wrote: > 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 > --------------------------------------------------------------------- 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]
