I'm new to struts too.  All this is my opinion, older hands may have better
explanations.

> 1) Struts is a framework for a web application (web server
> centric) not for
> an Enterprise J2EE Application (EJB centric).
> [srinivas] As per my reading till now I disagree with him. Struts does not
> limit us to go for  EJB

You are correct.  Struts presents the business model (your EJBs) to web
users.  Struts is the front end.  It does not constrain your business logic
in any way.  I'm using it as a front for a Forte 4GL based system, where the
struts layer communicates with the back end via XML.

> 2) Structs framework is designed based on the Model-View-Controller
> architecture and it wraps the Controller part and does a little
> bit for the
> View, but does nothing for the Model.
> [srinivas] I understand the strong point of this framework is
> Controller and
> View and it is upto developer to have a model. No limitations by
> framework.

Correct.  Struts is presentation only, it doesn't constrain the model.  It
is there to expose the model to a user, via a web interface.  A little bit
for the view?  I think it does a lot.

> 3) Must spend time to learn its syntax and structures
> [srinivas] Same with any other framework?

Same with any new style of development.  Gains come with a better
architecure.  The architecture constrains the way you develop and so points
you towards a "better" solution.

> 4)Even for a web application, developer still need to do the major work
> including business object, transaction management, and complicated
> connection pool management.
> [srinivas] I guess web app server provides transaction and connection pool
> management but still we need to develop our own business objects.

Yep, as per the model/presentation split covered above.

> 5) For EJB centric application, most work will be in EJB objects which has
> nothing to do with this framework
> [srinivas] Can EJB be part of this framework?

This framework is for presentation.  Pick a different framework for your
EJBs (isn't EJB in itself a framework?).  Struts just presents the EJB
functionality to the user...you have to do it somehow.  EJBs aren't usable
on their own...

> 6) If use Struts framework, our product will rely on its
> libraries which may
> have bugs and not so liable like Sun's java libraries. So it may cause
> maintenance problems.
> ??

Oooh look, it's the old "we can build this ourselves with no bugs in" vs
"lets uses this tried and tested code that many hundreds of developers are
using in their own products" argument.  Methinks you'll get better support
for bugs in Struts than bugs in Sun's code.

> 7) If we choose EJB centric design, all the transaction, session, thread,
> connection pool, and resource management will be very well handled by the
> EJB container. In the case of Struts, web container is used only
> as request
> dispatcher or request controller plus the View part
> ??

Correct.  But that's not a reason not to use Struts.

I would find the decision to use EJBs more difficult than the decision to
use Struts.

Hope my ramblings are useful!

Tim.



--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

Reply via email to