Hi Benoit, You can find the catalog of all the J2EE patterns including ValueObject Assembler at,
http://developer.java.sun.com/developer/restricted/patterns/J2EEPatternsAtAGlance.html The example code is at , http://www.phptr.com/corej2eepatterns/codeChap8_3.html The example on value object assembler is slightly different in implementation than the ones I have used, but the concept is essentially same. -karthik. [EMAIL PROTECTED] wrote: > Karthik, > > Could you please tell me where I can find articles, sample codes, etc > about ValueObjectAssembler ? > > -Benoit. > > -----Original Message----- > From: Karthikeyan M [mailto:[EMAIL PROTECTED]] > Sent: 06 February 2002 02:51 > To: [EMAIL PROTECTED] > Subject: Re: EJB and Stored-Procedures > > Hi Ted, > > You raised a good point and I completely agree with you. We use stored procs > to > speed up database intensive operations, through a > SLSB-->ValueObjectAssembler as > java object (persistence layer) model. I really don't know if anyone has > tried > EB & stored proc combination, and would like to hear their experience. > > -karthik. > > Ted Neward wrote: > > > Agreed. Using the stored proc presents problems if you use Entity Beans to > > access the data. I argue that you don't need the entity beans if you use > > stored proces--stored procedures provide much the same encapsulation that > an > > Entity Bean provides, no? How many layers of encapsulation does a given > > project really need, and should the data encapsulation layer be spread > > across two (or more) machines? > > > > Ted Neward > > {.NET || Java} Course Author & Instructor, DevelopMentor > > (http://www.develop.com) > > http://www.javageeks.com/tneward > > > > ----- Original Message ----- > > From: "Karthikeyan M" <[EMAIL PROTECTED]> > > To: <[EMAIL PROTECTED]> > > Sent: Monday, February 04, 2002 4:37 PM > > Subject: Re: [EJB-INT] EJB and Stored-Procedures > > > > > The point I was raising is that you would violate the data encapsulation > > that > > > the Entity Beans provide, if you use stored procs to access the same > data > > > (assuming this stored proc is used by some other EJB). This will not > make > > any > > > difference if the stored procs perform read-only operations or doesn't > > access > > > data maintained by other EBs. But, if they change the data that an > entity > > bean > > > is supposed to provide access to, then you might be in trouble. > > > > > > -karthik. > > > > > > Ted Neward wrote: > > > > > > > How is this any different from normal entity beans? The only > difference > > > > between a normal EB and one using a stored proc is that the stored > proc > > will > > > > be faster about retrieving its data. > > > > > > > > Ted Neward > > > > {.NET || Java} Course Author & Instructor, DevelopMentor > > > > (http://www.develop.com) > > > > http://www.javageeks.com/tneward > > > > > > > > ----- Original Message ----- > > > > From: "Karthikeyan M" <[EMAIL PROTECTED]> > > > > To: <[EMAIL PROTECTED]> > > > > Sent: Thursday, January 31, 2002 9:26 AM > > > > Subject: Re: [EJB-INT] EJB and Stored-Procedures > > > > > > > > > Also, > > > > > > > > > > Shouldn't the decision on how the entities handle the data be made > > > > carefully > > > > > when stored procs are involved. Stored procedure is more like a > > > > background > > > > > access to data that an entity bean is supposed to provide uniform > > access. > > > > If a > > > > > stored procedure alters the data of another entity bean, what will > > happen > > > > the > > > > > next time someone invokes business methods on the other entity bean? > > This > > > > is > > > > > more so when optimizations are involved in how the ejbLoad() and > > > > ejbStore() are > > > > > executed. > > > > > > > > > > -karthik. > > > > > > > > > > Dmitri Colebatch wrote: > > > > > > > > > > > afaik none of the CMP engines around will elt you map to stored > > > > procedures, > > > > > > but I cant see any reason why a BMP entity bean couldn't use them. > > I'm > > > > > > assuming that the stored procedures will achieve the same > > functionality > > > > as > > > > > > insert/update etc. > > > > > > > > > > > > the only thing I can think of is that you might find you are > forced > > into > > > > > > using very coarse entity beans because of the stored procedure > setup > > > > (I"m > > > > > > assuming they prevent you from breaking any foreign key > constraints > > > > etc.). > > > > > > > > > > > > my 2c > > > > > > > > > > > > cheers > > > > > > dim > > > > > > > > > > > > ----- Original Message ----- > > > > > > From: "Benoit Aumars" <[EMAIL PROTECTED]> > > > > > > To: <[EMAIL PROTECTED]> > > > > > > Sent: Friday, February 01, 2002 12:34 AM > > > > > > Subject: EJB and Stored-Procedures > > > > > > > > > > > > > Hi, > > > > > > > I hope someone might give me some comments about how a > > > > > > > stored-procedure can be used with an entity bean. > > > > > > > > > > > > > > I have an application which use a database with the following > > rules : > > > > > > > 1. no users have an INSERT, UPDATE, or DELETE access into the > > > > database. > > > > > > > 2. put every SQL statement, i.e. INSERT, UPDATE, DELETE, or > > SELECT, > > > > > > into > > > > > > > a > > > > > > > stored-procedure. > > > > > > > 3. all stored-procedures are owned by DBO. > > > > > > > 4. users are only allowed to execute a SELECT statement or > > > > > > > run/execute a stored-procedure. > > > > > > > > > > > > > > Here are my questions : > > > > > > > a. how to use a stored-procedure with an entity bean ? > > > > > > > b. the database contains about 125 tables, with about 10 > tables > > > > > > contains > > > > > > > more > > > > > > > than 10.000 records. How this can be 'mapped' ? > > > > > > > > > > > > > > > > > > > > > Thanks, > > > > > > > Benoit Aumars. > > > > > > > > > > > > > > > > > > > > > > > > > > > =========================================================================== > > > > > > > To unsubscribe, send email to [EMAIL PROTECTED] and include > in > > the > > > > > > body > > > > > > > of the message "signoff EJB-INTEREST". For general help, send > > email > > > > to > > > > > > > [EMAIL PROTECTED] and include in the body of the message > > "help". > > > > > > > > > > > > > > > > > > > > > > > > > > =========================================================================== > > > > > > To unsubscribe, send email to [EMAIL PROTECTED] and include in > > the > > > > body > > > > > > of the message "signoff EJB-INTEREST". For general help, send > email > > to > > > > > > [EMAIL PROTECTED] and include in the body of the message > "help". > > > > > > > > > > > > > > > > > =========================================================================== > > > > > To unsubscribe, send email to [EMAIL PROTECTED] and include in > the > > > > body > > > > > of the message "signoff EJB-INTEREST". For general help, send email > > to > > > > > [EMAIL PROTECTED] and include in the body of the message "help". > > > > > > > > > > > > > > > > > > > =========================================================================== > > > To unsubscribe, send email to [EMAIL PROTECTED] and include in the > > body > > > of the message "signoff EJB-INTEREST". For general help, send email to > > > [EMAIL PROTECTED] and include in the body of the message "help". > > > > > > > > > > > =========================================================================== > > To unsubscribe, send email to [EMAIL PROTECTED] and include in the > body > > of the message "signoff EJB-INTEREST". For general help, send email to > > [EMAIL PROTECTED] and include in the body of the message "help". > > =========================================================================== > To unsubscribe, send email to [EMAIL PROTECTED] and include in the body > of the message "signoff EJB-INTEREST". For general help, send email to > [EMAIL PROTECTED] and include in the body of the message "help". > > ************************************************************ > JLT Management Services Limited > 6 Crutched Friars, London EC3N 2PH. Co Reg No 1536540 > Tel: (44) (0)20 7528 4000 Fax: (44) (0)20 7528 4500 > http://www.jltgroup.com > ------------------------------------------------------------ > The content of this e-mail (including any attachments) as > received may not be the same as sent. If you consider that > the content is material to the formation or performance of > a contract or you are otherwise relying upon its accuracy, > you should consider requesting a copy be sent by facsimile > or normal mail. The information in this e-mail is > confidential and may be legally privileged. If you are not > the intended recipient, please notify the sender immediately > and then delete this e-mail entirely - you must not retain, > copy, distribute or use this e-mail for any purpose or > disclose any of its content to others. > > Opinions, conclusions and other information in this e-mail > that do not relate to the official business of JLT > Management Services Limited shall be understood as neither > given nor endorsed by it. Please note we intercept and > monitor incoming / outgoing e-mail and therefore you should > neither expect nor intend any e-mail to be private in nature. > > We have checked this e-mail for viruses and other harmful > components and believe but not guarantee it virus-free prior > to leaving our computer system. However, you should satisfy > yourself that it is free from harmful components, as we do > not accept responsibility for any loss or damage it may > cause to your computer systems. > ************************************************************ > > =========================================================================== > To unsubscribe, send email to [EMAIL PROTECTED] and include in the body > of the message "signoff EJB-INTEREST". For general help, send email to > [EMAIL PROTECTED] and include in the body of the message "help". =========================================================================== To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message "signoff EJB-INTEREST". For general help, send email to [EMAIL PROTECTED] and include in the body of the message "help".
