Hi Rick,
I'll tell you my opinion if you want to listen :-)
I know that it is unpopular and majority of JBoss developers don't
agree with me.
But I continue to advertise my favorite approach :-)
On Wednesday 10 January 2001 03:33, Rick Horowitz wrote:
> I am considering using Castor with JBoss and am trying to work out
> the most appropriate architecture for my application. I'm also
> using Tomcat for a servlet front end for this app, with Struts MVC
> architecture and custom JSP tags. In addition, I'm looking at using
> EJBDoclet, which I've found does a very nice job of generating the
> EJB classes & interfaces. I would appreciate any thoughts, and in
> particular, comments from anyone who's using Castor with JBoss, as
> to how to best use these technologies together. Alternatively,
> please let me know if there are any gotcha's that will make this
> technology mix difficult or inadvisable to use.
Our company uses Castor with JBoss, but our project is still in
development, so probably we haven't met some existing problems yet.
> Here are my questions: (I only have a cursory understanding of
> Castor at this point, so please forgive me for any stupid
> questions):
>
> 1. I would like to use Castor to manage persistence of EJB BMP
> entity beans, given JAWS' inability at the moment to support
> dependent objects. An EJB with no dependent objects would have a
> single Castor persistent object associated with it, whereas an EJB
> with dependent objects would implement those dependent objects as
> Castor dependent objects. If I use an architecture like this, is it
> best to let Castor directly persist the EJBs, themselves, or is it
> better to store the data for an EJB in a separate Castor data
> object?
I believe that EJB class shouldn't coincide with Castor data object.
EJB class should hold some data object internally, use Castor
db.load(), db.update(), db.create(), db.remove() to implement
jdoLoad(), jdoStore(), jdoCreate(), jdoRemove().
Probably you can automate this work with the help of some code
generation tool.
EJB class may or may not have get/set methods for all fields of
Castor object, but it should have get/set methods for the whole
Castor data object used as a value (bulk) object.
In general independent Castor data objects may not correspond to some
BMP, but only if you need BMP for some non-trivial remote operations,
some business logic performed for one object instance. Otherwise you
can use Castor data objects from Session Beans or even from other
Entity Beans directly, without intermediate BMP (it would be faster
BTW).
Even if you have two BMPs "hosting" two Castor data objects, you can
use Castor data object from "foreign" BMP.
In other words, I believe that it is okay to separate some Entity
into two classes, BMP as a remote object and JDO as a value
object. For me it is better approach than to claim that Entity ==
EntityBean and then to solve performance and network traffic problems
inventing various unclear tricks.
> Also, for EJB with dependent objects, I assume that
> whichever object is chosen as the independent object that Castor
> persists for the EJB, that object must maintain references to the
> dependent objects for that EJB. Is this correct?
Yes, sure.
> 2. I would like to avoid duplicating data objects as much as
> possible. One thing that I've noticed with the whole J2EE
> architecture is that there is a lot of opportunity to duplicate
> objects that do roughly, or exactly, the same thing. For example:
> a) Struts uses JavaBeans that extend
> org.apache.struts.action.ActionForm to pass data from an HTML form
> in a JSP to the servlet for processing. In addition, both these and
> other, non-ActionForm JavaBeans are used to pass data back to a JSP
> for output to the user.
> b) It is recommended that data objects be used to pass bulk data
> between the EJB client and the EJB in order to minimize network and
> transaction overhead. Question: is it a bad idea to use Struts
> ActionForm beans as these data objects? The tradeoffs seem to be:
> if yes, then it increases the coupling between the EJBs and the
> front end technology - BAD, but if no, then it eliminates the need
> to implement and maintain an additional data object for the EJB.
> Opinions?
I would use Castor data objects: you can pass them to client or to
servlet, then return them back (so called "long transaction") and
update in the database. Moreover, Castor supports dirty checking for
long transactions.
If you need decoupling, you can introduce additional client interface
which is implemented by Castor data object, so that client works with
this interface and you are free to change the implementation.
However, I didn't use this approach.
> c) EJB dependent objects - these, too, could theoretically be
> implemented by the same JavaBeans used to pass data between JSP
> pages and servlets. For example, if a user enters customer
> information on an HTML form, a JavaBean could be used to pass the
> customer's address info to the servlet for processing (let's call
> this bean AddressBean). If the Customer EJB has a dependent object
> containing the customer address, the AddressBean could be used not
> only as a bulk data object to pass the address data to the Customer
> EJB, but as the dependent Address object referenced by the Customer
> EJB. Again, this increases linkage between the front end and the
> back end, but reduces the number of classes that need to be
> implemented and maintained. Opinions?
Again, my choice is using Castor data objects for that.
> 3. Some entity beans will reference other entity beans. AFAICT,
> JAWS can automatically manage the persistence relationships between
> entity beans, but cannot manage collections of references to other
> entity beans. I'm wondering if, and if so, how Castor can be used
> to manage this sort of relationship. For example if I have the
> following EJB entity bean objects:
>
> EntityAEJB
> DependentA1 - dependent object of EntityAEJB
> DependentA2 - dependent object of EntityAEJB
> EntityBEJB
> EntityB1EJB extends EntityBEJB - subclass of EntityBEJB
>
> ....and EntityAEJB contains a collection of EntityB1EJB objects,
> can Castor manage the persistence relationships correctly? I'd use
> BMP for all entity beans in this scenario to avoid having to deal
> with interactions between Castor and JAWS. What happens if Castor
> tries to persist EntityAEJB when it gets to its references to
> EntityB1? Those references would refer to the remote interface
> EntityB1, not EntityB1EJB. Would this work in Castor if the actual
> data for these entities is stored in the EJBs themselves? Would it
> work if the data for the EJB is stored in a subsidiary Castor data
> object? I'm definitely confused about this point...
I think I have already answered to this.
Regards,
Oleg
--
--------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
List Help?: [EMAIL PROTECTED]
