I like MVC as per : http://www.basebeans.com/struts.jsp (and just the
summary part)
Here is Sun's approach, which I think just sells more hardware, from
their web site:
"The key design pattern used in the Java Pet Store demo is the
Model-View-Controller architecture, which separates three distinct forms
of functionality within the application. To learn more about the
Model-View-Controller architecture in the Java Pet Store demo, read
Building Blocks of a J2EE Application from the previous release.
[Java[tm] Pet Store Demo]
JavaTM Pet Store Demo
New in Release 1.3
The Java Pet Store represents a typical e-commerce application,
presenting views of products and services for sale, including cats,
dogs, fish, exotic iguanas, and reptiles. The application incorporates
the following technologies:
* The JavaServer PagesTM (JSPTM) framework
* Java Servlet APIs, including filters and listeners
* The Java Message Service (JMS)
* Enterprise JavaBeansTM (EJBTM) components, including
container-managed persistence (CMP), message driven beans (MDB), and the
EJB Query Language
* Java Foundation Classes/Swing GUI (J.F.C./Swing) components for a
rich client user interface launched via Java Web Start software
* Java APIs for XML
* Extensible Style Sheets for Transformation (XSLT)
* Reusable web application framework
The application takes and processes orders, managing credit card
information, user logins, shipping information, and shopping cart sessions.
"
Do you see how this is to complex? This is why I think people give up
and go to Microsoft .NET. I would say a large majority of clients are
moving to .NET.
KISS. (Keep it simple)
To me alternative is Struts as implementation of a MVC Frame work, which
is a sweet spot, productively applied to a business application. (There
are others who like coding just to get fun technology). To me EJBs were
for distributed applications. I think less then 5% of applications out
there need to be distributed, hence I ask a question why do you need an
EJB? (Does anyone deploy client side Java?).
Or even this: http://java.sun.com/products/ejb/index.html
What is the business case?
Is it:
"Enterprise JavaBeans servers reduce the complexity of developing
middleware by providing automatic support for middleware services such
as transactions, security, database connectivity, and more.
". Is this true, based on your experience with developing EJB? CMP with
transactions, this comes in handy? Should I only use it when I need
middleware? What is middleware? I must need it.
I think we all make our choices for our applications and what I chose
may not be correct for your application.
/* Flame: How can I change the business requirements spec for this
application so I could use message driven beans? (if you do not get it,
don't worry */
I would use Action as just an application controler.
Maybe you can just do a FormBean as just a bean and do a DAO by puting a
on it for DAO. (And if you go Swing.... use the same FormBean, Swing
knows RowSet).
Vic
the FormBean dude.
Stefan Frank wrote:
> Hi,
>
> i'm not very fond of these Helper-Classes: Most of the time, they only add
> an additional Layer which just proxies calls to the SessionBeans: The
> benefit you get is mostly, that you can wrap all ejb-related errors inside
> the Helpers. This saves you some coding, but most of the time you want to
> react on a RemoteException in a different way the than on a finder
> Exception.
>
> We code the EJB-Access driectly in the Actions and try to keep the Actions
> small by keeping most of the Code inside SessionBeans (which is a generally
> a good idea, as you can reuse this code in context's where Struts is not
> applicable, eg. with a Swing-Client). In order for this to work, it's a good
> idea, to use a
> SessionFacade(http://java.sun.com/blueprints/patterns/j2ee_patterns/session_
> facade/index.html) to avoid having to code against numerous ejb's in your
> action - in our experience, this is sufficient: A helper-class just doubles
> the Methods of the Facade.
>
> Check out, if portability from an ejb-Architecture to a pure-jdbc
> Architecture is really a requirement, or if it even is possible: I'm not
> really sure, wether it pays to code independently of the j2ee-architecture,
> as it means to wrap most of the main-features (EntityBean, SessionBean, MDB,
> jndi and so on) - with applicationspecific classes that abstract out the
> functionality: I think in projects under high pressure you throw away all
> the benefits of j2ee with this approach.
>
> So, by keeping the code in the actions small, we us Actions in a
> "Command"-way: which works quite nicely for us: As there is not so much code
> in the action, we don't have problems with writing new ones or changing the
> old ones.
>
> hope this helps
> greetings
> stf
>
> ---
> vierundsechzig.de
> friedensallee 7-9
> 22765 hamburg
> telefon +49 (040) 306033 -43
> telefax +49 (040) 306033 -64
>
> http://www.vierundsechzig.de
> mailto:[EMAIL PROTECTED]
>
>
>
>
>
>
>
>
>>-----Ursprungliche Nachricht-----
>>Von: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
>>Gesendet: Mittwoch, 19. Dezember 2001 01:01
>>An: Struts Users Mailing List
>>Betreff: accessing EJB components from a Struts application?
>>
>>
>>
>>Hi all,
>>
>>after browsing the FAQ and searching the mailing list archive,
>>I have not yet found a 'premium way' to go for EJB business logic
>>integration into a Struts application.
>>
>>It's pretty clear that the EJB stuff should go into the action classes.
>>I also saw hints that it might be useful to add another layer between
>>the action classes and the entity/session beans in order to keep the
>>action classes small and independent from the underlying business logic
>>tier architecture.
>>
>>So the recommended architecture would be
>>
>>action class <-> ejb 'helper' class <-> EJB Session/Entity Bean
>>
>>which allows for e.g. replacing the EJB tier by direct JDBC
>>database access without having to modify the action classes.
>>
>>Is the presented view correct/recommendable, or have I probably missed
>>some important developments concerning the Struts<->EJB issue?
>>Besides selected threads of this mailing list, are there any
>>instructive resources/links regarding the topic?
>>
>>Regards,
>>
>>--
>>Thomas Corte
>><[EMAIL PROTECTED]>
>>
>>
>>
>>
>>--
>>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]>
>
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
