Sorry that is three questions, not two.

Vikram


-----Original Message-----
From: Vikram Goyal01 
Sent: Thursday, March 14, 2002 10:14 AM
To: Struts Users Mailing List
Subject: RE: Use of stuts in J2EE


Hi Dave,

Thanks again for your valuable comments. Two questions..

1. Is this strategy that you described the part of any pattern? 
2. Isnt this strategy inefficient? As you have to create two objects which hold the 
same data and have to make sure that data is copied from one to another all the time?
3. Finally, is it possible to have some code samples? 

Thanks and regards,

Vikram Goyal

-----Original Message-----
From: Dave J Dandeneau [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, March 13, 2002 5:40 PM
To: Struts Users Mailing List
Subject: RE: Use of stuts in J2EE


We have created value objects that we store within our form. The value objects a 
implement different interfaces and the forms have these objects has member variables. 

For instance a registration form may have a few fields that aren't persisted and then 
a registrationInput object which implements the address interface and the security 
interface. We pass the inputs directly to the commands and then to the EJBs. The input 
value objects are not tied to web / struts implementation and can be reused.

Because both the EJBs and the input objects implement the same interfaces we can use 
helper methods to copy properties from one to another. 

Thanks,
dave

-----Original Message-----
From: Vikram Goyal01 [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, March 13, 2002 3:52 AM
To: Struts Users Mailing List
Subject: RE: Use of stuts in J2EE


Hi Dave,

Thanks for that info. I have one question.

When your formbean captures the data that the user has submitted, how do you pass this 
data to the app layer? If you pass the same form bean, then your app layer is not 
usable by other clients (or they will also have to implement struts). Basically my 
question is, how do you process your form bean into a data object? If you create 
another data object at this point, isnt that a performance overhead?

Rgs
Vikram

-----Original Message-----
From: Dave J Dandeneau [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, March 13, 2002 10:10 AM
To: [EMAIL PROTECTED]
Subject: RE: Use of stuts in J2EE


We are currently implementing a j2ee / struts project. If I had any advice to you it 
would be to make sure you read up about common j2ee patterns. They can save you a lot 
of time and help you avoid some of the common EJB problems. We are using a command 
pattern which works very well. It is similiar to a session facade pattern where there 
are session beans that run all of the logic on the ejb container and send only the 
results back to the actions. This helps reduce network overhead, and makes 
transactions very simple. There are a million different patterns out there, and the 
most common ones are available at Sun's site: 
http://developer.java.sun.com/developer/technicalArticles/J2EE/patterns/

Other than that I don't think that working with struts and EJBs is much different than 
working with EJBs on a non-struts application. 

Thanks,
dave dandeneau

-----Original Message-----
From: Vikram Goyal01 [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, March 12, 2002 10:50 PM
To: [EMAIL PROTECTED]
Subject: Use of stuts in J2EE


Hi all,

I am implementing a J2EE (Enterprise application with EJBs) project using struts. If 
anyone has done a similar project and would like to share some guidelines please mail 
back to me. Alternatively, if you have any online pointers, articles etc. please 
forward these as well.

Regards
Vikram Goyal

--
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]>


--
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]>

Reply via email to