If I had more time I would comment on this more fully as it seems some of the ideas being expressed here are off-the-mark and short-sighted.
I don't mean to go on a rant here, but my job would be much easier if we just used JSPs and JDBC. To heck with those creative types; if they can't read our Java code then they shouldn't have a role in development. If they want to change the look and feel of the application, let them just try to work around my code. And why should I care about extensibility, flexibility, maintainability, robustness, and scalability? I'm being measured on whether I deliver the system by a specific date. Let the maintenance team figure out that other stuff. I mean, don't they have the other 80% of the software's life to do that? All I have is the first 20%! Model-View-Controller -- what is up with that anyway? Aren't web applications just about displaying something in a browser? If the user can't see it, it doesn't matter. All that pattern garbage is just wasteful muttering. How often do application requirements really change anyway? I think those guys at Prentice-Hall just made it all up because they wanted to sell more books. All that stuff about transactions and security. Isn't that why I buy a database? And why should I let the people deploying the application make any decisions? They didn't help me when implementing the application. Why should I care whether it is easy to deploy and administer? Oh yeah, while I'm on the topic, this whole open source thing is really worrisome. I mean, how can I trust that code? And those licenses -- don't they say that I have to open up and give away everything that I write if even one line of open source is in my application? And why is that there seem to be multiple solutions to the same problem? Jeez -- Jakarta even has two different regular expression implementations. I wish one vendor would step in and give me just one way to do everything on one hardware platform in one development environment with a fixed set of services. Don't all good ideas come from one place anyway? Excuse me, I've got some JSP/JDBC work to do -- or was that ASP/ODBC? See! Now you got me all confused! ;-) Best regards, Jim Cakalic > -----Original Message----- > From: Chris Smith [mailto:[EMAIL PROTECTED]] > Sent: Wednesday, December 19, 2001 8:21 AM > To: Struts Users Mailing List > Cc: [EMAIL PROTECTED] > Subject: Re: AW: accessing EJB components from a Struts application? > > > 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_pat > terns/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]> > <font size="1">Confidentiality Warning: This e-mail contains information intended only for the use of the individual or entity named above. If the reader of this e-mail is not the intended recipient or the employee or agent responsible for delivering it to the intended recipient, any dissemination, publication or copying of this e-mail is strictly prohibited. The sender does not accept any responsibility for any loss, disruption or damage to your data or computer system that may occur while using data contained in, or transmitted with, this e-mail. If you have received this e-mail in error, please immediately notify us by return e-mail. Thank you.
