I like this description, mainly because it sounds like what I have been
doing. Something like this might make a good section in the documentation -
Struts & EJBs. I would consider the stateless session beans part of the
model because they contain business logic. You also talk about "basic value
checking of attributes". Would you also do this same value checking in the
ActionForm validate method?
Thanks, Hal
> -----Original Message-----
> From: Handy, Steve [mailto:[EMAIL PROTECTED]]
> Sent: Thursday, March 29, 2001 6:04 PM
> To: '[EMAIL PROTECTED]'
> Subject: RE: Communicating with EJB's from Action
>
>
> Chris,
>
> What we've done is this:
>
> - Put a layer of business logic session stateless beans above
> the entity
> EJBs. The beans in this layer have methods that perform
> specific business
> functions.
>
> - Have the Action classes translate the user's click into one
> or more calls
> to the business logic layer. We don't pass the ActionForm to
> the business
> layer, because the ActionForm is too close to the view. If
> we need to pass
> a set of related data items to the business layer, we do it
> with a value
> object that represents the kind of businessy attributes you'd
> find in an
> EJB.
>
> So, we partition responsibility like this:
>
> JSPs: rendering. To us this is View.
>
> Actions: translation of user actions into business operations
> (if necessary)
> and always a decision about what to display next. This layer doesn't
> implement business operations, but knows what high level
> business operation
> it needs to call to fulfill the user's request. We consider
> this layer to
> be Controller.
>
> Business session stateless beans: fulfillment of business
> function. For
> cross-entity operations, do the details here. Speak in only
> business terms,
> not in any view terms. Completely independent of Struts.
> Still Controller
> for us.
>
> Entity EJBs: Fulfill single-entity business operations here
> (like basic
> value checking of attributes). Of course, these EJBs also
> give us all the
> entity-bean function we get from the container. Only this
> layer knows about
> the database. In general, we don't let an entity EJB
> interact with another
> entity EJB; we leave this to the session stateless beans
> above. This is our
> Model.
>
> Utility classes:
> ActionForms - for passing view-specific information around
> between Actions
> & JSPs, etc.
> Value objects - for passing entity-specific information
> around, including
> up to and down from the Actions.
>
> Steve
>
> -----Original Message-----
> From: Assenza, Chris [mailto:[EMAIL PROTECTED]]
> Sent: Thursday, March 29, 2001 4:59 PM
> To: '[EMAIL PROTECTED]'
> Subject: Communicating with EJB's from Action
>
>
> Hello! :)
>
> Our dev team for a big enterprise app has been going back and
> forth on how
> to send the data from the ActionForm to a Session bean. We
> have a number of
> options and I was hoping for some feedback because we've had
> enough talk and
> its time to decide! :) (Our architecture is as of now to use
> only Session
> Beans, but we will probably start wrapping Entity beans with
> Session beans
> eventually).
>
> 1) Send the ActionForm to the EJB from Action perform()
> Pros: Easy and less work
> Cons: Defeats the purpose of Struts in that the
> Business Logic is no
> longer self-contained and independent of the V in MVC :). If
> for whatever
> reason we overhaul the front end and remove Struts, we're not
> in the ideal
> position to do so.
>
> 2) Create a special utility class that with special methods, that when
> invoked from the Action perform() method, will put the data
> from ActionForm
> into a HashTable. Then, we'll pass that object to the EJB
> and do whatever
> business logic is necessary.
>
> 3) JMS - Sort of an adaptation of the number 2 as JMS uses
> HashMaps and the
> like but it follows a specific spec and has a lot more to it
> then what we'd
> be doing above. However, none of us really know much about
> JMS yet. :|
> Obviously we can learn, but is it a recommended path to
> follow from your
> experience? (in regards to Struts specifically as well).
>
> 4) RMI or RMI-IIOP. Create a remote object within the client
> and pass the
> remote reference to the EJB. The EJB can then use this
> reference to make
> callbacks to the client. Not sure about this one either, seems rather
> inefficient.
>
> Oh, and one other question, since DataTable (Java collection)
> is basically
> made up of vectors, can one use the iterate tag to move through it?
>
> Any thoughts or experiences?? :)
>
> Thanks,
>
> Chris Assenza
>
