struts-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Joe Barefoot" <Joe.Baref...@motiva.com>
Subject RE: struts + EJBs?
Date Wed, 16 Oct 2002 21:35:04 GMT
> -----Original Message-----
> From: V. Cekvenich [mailto:vicc@users.sourceforge.net]
> Sent: Wednesday, October 16, 2002 2:09 PM
> To: struts-user@jakarta.apache.org
> Subject: Re: struts + EJBs?
> 
> 
> You have MQ, and it seems that you know what you are doing, and have 
> good real reasons to use it. EJB have a place for sure.
> And I would not argumet with experienced developers, they 
> know what they 
> are doing.
> 
> One thing is that I would not call EJB overkill if it is used 
> *only* for 
> persistence, since it takes x% longer to develop and they execute y% 


Are you implying that Entity beans take longer to develop that a JDBC-based DAO with hand-crafted
SQL?
If so, surely you jest. 

If you mean the extra interfaces and config info for session beans....doesn't take much longer
to create those, and you can even use a tool like xdoclet to generate them for you if you
want.  It takes me no longer to create an EJB than any other Java class.


> slower and they cost z$ more to operate. Then those people go to .NET.
> So, there are some that use it as an underkill.
> 
> More of using a fork, when you need a spoon. Hard to compare. Yes you 
> can eat a sup with a fork, and spoon a peace of BBQ, but...
> 
> Also... I think JDO is OK, but... you cant do most sql, like 
> self join 
> adjecacny//nested, supertypes, etc. etc. and most db design 
> needs andy 


Not true.  Both OJB and Castor handle nested objects and supertypes.  You can always 'escape'
to the JDBC/SQL world in your EJB Session bean servicer objects if need be to execute complex
queries or to optimize very frequent accesses.  

If you use Entity beans w/ CMP rather than your choice of O/R tool with session beans, then
you're stuck with the container's persistence implementation.  So, if your argument is based
on not using CMP, I'd tend to agree.  If your argument is against the EJB framework in general....happy
coding. :)


> SQL string, not some _QL, SQL. I have been happy with DAO, very fast, 
> any SQL.


> 
> .V
> 
> Kevin.Bedell@sunlife.com wrote:
> > 
> > 
> > 
> > 
> > Vic,
> > 
> > In general I agree with much of this sentiment. But not all of it.
> > 
> > I've been using WebLogic for a while and have yet to run 
> into a situation
> > where EJB's didn't perform fast enough. We have a bunch of 
> apps full of
> > entity beans that all work fine. And I've had to build some 
> complex stuff
> > that required weird transaction management - like commiting 
> a database
> > write only after I was sure I had correctly read from a JMS 
> queue and
> > passed the data successfully to MQSeries - all three 
> interfaces had to be a
> > single transaction that rolled back if any one had a 
> problem. Using a J2EE
> > container to manage all transactions made all this much simpler.
> > 
> > And the developers in my group have gotten so where we can 
> knock out EJB's
> > pretty fast. It doesn't slow us down.
> > 
> > I think Weblogic is a great product. I think trading it in 
> for just a web
> > container would be a big step backwards. JMS alone 
> justifies having a full
> > J2EE container.
> > 
> > What I was trying to say in my earlier repsonse was that I 
> think its great
> > to have the container and all it offers - but that the 
> learning curve isn't
> > easy and sometimes it's overkill.
> > 
> > 
> > 
> > 
> --------------------------------------------------------------
> -------------
> > This e-mail message (including attachments, if any) is 
> intended for the use
> > of the individual or entity to which it is addressed and may contain
> > information that is privileged, proprietary , confidential 
> and exempt from
> > disclosure.  If you are not the intended recipient, you are 
> notified that
> > any dissemination, distribution or copying of this communication is
> > strictly prohibited.  If you have received this 
> communication in error,
> > please notify the sender and erase this e-mail message immediately.
> > 
> --------------------------------------------------------------
> -------------
> 
> 
> 
> 
> --
> To unsubscribe, e-mail:   
<mailto:struts-user-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:struts-user-help@jakarta.apache.org>


--
To unsubscribe, e-mail:   <mailto:struts-user-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:struts-user-help@jakarta.apache.org>


Mime
View raw message