Right - the gain from using Local Entity beans is that you don't have to go through the normal object serialization and pass by value. Instead, local references are used when doing EJB invocation within the same VM as the EJB - usually when you use the stateless wrapper->Entity bean pattern (which I use). I still want to be able to offer an API to retrieve a complete user account, with the proper data object graph filled out. This means that either the data objects need to have the similiar relationships mapped, or I need to write some sort of wrapper to store the proper 1..n relationships my self. I guess a third would be to abandon the data objects XDoclet generator and write my own :(
So, with that, any thoughts on what XDoclet should be doing, and where I should be jumping in? Oh, and remote entity beans aren't deprecated, its just that the most common and appropriate pattern is stateless wrappers to entity beans, so remote entities should become less the norm. You may still want to offer remote access to entity beans for certain situations, though, and so I can't imagine they would do away with them completely. Remote entity = course grained business object Local entity - fine grained business object, usually dependents With EJB 2.0, they are getting closer to what IBM San Francisco had in their framework with independent and dependent objects (mirroring the database architect's own independent and dependent relationships in an ER schema). Thanks, James ----- Original Message ----- From: "Aslak Helles�y" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> Sent: Thursday, December 13, 2001 1:27 PM Subject: Re: [Xdoclet-user] Data Objects and CMR > Hi again, > > -So the performance hit you're trying to overcome is that of having a db r/w > for each field? -And use a transaction for the setData/getData method so > that all fields are read/written in one shot? If that's it, I'm with you. > > I think the problem of having the generated data objects support relations > is that all data must be loaded into them. What if you have a long chain of > relations between beans/tables. How far do you go? You might end up loading > the entire database into the dataobjects, and that would be a pretty nasty > performance hit ;-) > > The way I see it there are two solutions if you absolutely have to do > everything in one transaction: > > 1) Do it the way you're doing it today, with a helper class to establish > relationships on the dataobjects. Perhaps XDoclet could generate such > classes? > > 2) Have multiple setData/getData methods accepting different structures of > data objects. (Not possible in today's XDoclet). It would be like this: > > setDataEmployeeOnly( EmployeeData d ); > setDataEmployeeAndDepartments( EmployeeData d ); > setDataEmployeeAndDepartmentsAndProjects( EmployeeData d ); > > Likewise for getters. It seems like a difficult one to implement if you ask > me. > > Am I making any sense at all? > > Aslak > > > >From: "Glenn R. Kronschnabl" <[EMAIL PROTECTED]> > >To: [EMAIL PROTECTED] > >Subject: Re: [Xdoclet-user] Data Objects and CMR > >Date: 13 Dec 2001 11:32:45 -0600 > > > >I wonder if this is "the right way". If you use EJBLocal's without > >dataobjects via JSP/taglibs, what transaction type do you use? If you > >use "required" on each of the fine grained getter methods, each fine > >grained get method will result in a database read/write. If you use > >"supports" then the result is vendor specific. Under weblogic, an > >unspecified tx results in a local tx on the entity bean, again, a db > >r/w. > > > >Given the performance hit, I think we're always going to need value > >objects... unless I'm missing something or I don't understand tx's. > > > >Glenn > > > >On Thu, 2001-12-13 at 07:40, rinkrank clob wrote: > > > My understanding of the EJB 2.0 spec is that remote entity beans are > > > "deprecated". You should only use local entity beans. > > > > > > Data objects were invented mainly to avoid calling remote entity beans > >and > > > reduce network traffic. Therefore, if remote entity beans are not used, > >I > > > don't see the reason to use data objects either. Just use the local > >entity > > > beans (which have the CMR support, right?). > > > > > > In other words, my understanding of EJB 2.0 is that data objects go down > >the > > > drain with remote entity beans. You'll never need them again. Would this > > > work for you? I know you're a local-fan ;-) > > > > > > My 2 cents on J2EE patterns ;-) > > > > > > Aslak > > > > > > >From: "James Higginbotham" <[EMAIL PROTECTED]> > > > >To: <[EMAIL PROTECTED]> > > > >Subject: [Xdoclet-user] Data Objects and CMR > > > >Date: Wed, 12 Dec 2001 20:23:28 -0600 > > > > > > > >Anyone out there using CMP 2.0 and container managed relationships > >(CMRs) > > > >with XDoclet? How are you handling the data objects being generated > >without > > > >relationships? My guess is that I would write a simple class to wrap my > > > >master and detail objects, but this somehow seems wrong. > > > > > > > >For example, I have a UserAccountData, UserPhoneData, and > >UserAddressData. > > > >Right now, it is a 1-1 mapping, so I would create a UserAccountModel, > >which > > > >held 1 reference to an instance of each. My stateless session bean > >would > > > >then accept the model in its createAccount() method and create the 3 > >CMPs > > > >appropriately. > > > > > > > >Anyone have any suggestions on this? > > > > > > > >Thanks, > > > >James > > > > > > > > > _________________________________________________________________ > > > Get your FREE download of MSN Explorer at > >http://explorer.msn.com/intl.asp. > > > > > > > > > _______________________________________________ > > > Xdoclet-user mailing list > > > [EMAIL PROTECTED] > > > https://lists.sourceforge.net/lists/listinfo/xdoclet-user > > > > > > > >_______________________________________________ > >Xdoclet-user mailing list > >[EMAIL PROTECTED] > >https://lists.sourceforge.net/lists/listinfo/xdoclet-user > > > _________________________________________________________________ > Send and receive Hotmail on your mobile device: http://mobile.msn.com > > > _______________________________________________ > Xdoclet-user mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/xdoclet-user > _______________________________________________ Xdoclet-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/xdoclet-user
