action - delegate - facade
I've just been perusing the archive to check out what people have been saying about struts to EJB interfacing. One thing that occurs to me is that the only reason mentioned for having a business delegate layer between the Actions and the Session Facade is to allow for loose coupling of the struts-dependent code with the EJB dependent code. How necessary is that? If you choose to drop EJB and go with, say Hibernate, you would have to modify the interface, whether it is the Action - Facade interface or the Delegate - Facade interface. Or have I missed an important other reason for the existence of the Delegate layer? Adam -- struts 1.1 + tomcat 5.0.16 + java 1.4.2 Linux 2.4.20 Debian - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: action - delegate - facade
Adam, IMHO the Business Delegate pattern abstracts the client from knowing your business implementation, whether it be EBJ, JDO, POJO, roll your own. The client interfaces with the Business Delegate and not its implementation. For example, if you have an Action (client) interface with the Business Delegate instead of directly with a SessionFacade, then you can change the underlying implementation of the Business Delegate without changing anything in the client. If your really paranoid (or prepared), you can use the Abstract Factory pattern which you could then initialize/subclass to create the appropriate Business Delegate implementations (EJB, JDO, main frame). Also by using a Business Delegate the client isn't exposed to implementation details such as (if your using EJB) looking up the appropropriate EJB or handling implementation specific exceptions. The Business Delegate becomes a high level abstraction of the business rules raising application level exceptions when error occur to which the client can respond appropriately. So, you wouldn't necessarily have to modify the Delegate-Facade interface. The interface itself remains unchanged. You have to use a different implementation. That is where the factory comes in. I imagine you could do something like the following: Properties props = // get initialization properties // to initialize factory to return EJB BD implementations BusinessDelegateFactory bdf = BusinessDelegateFactory.init(props); In your client, suppose AccountBD is your BusinessDelegate interface: BusinessDelegateFactory bdf = BusinessDelegateFactory.getInstance(); AccountBD accountBD = (AccountBD)bdf.createBusinessDelegate(AccountBD.BD_NAME); So you just end up "plugging" in new implementations as needed. Anyhow, that's my interpretation of the some of the forces behind the pattern and an idea on implementing it. Here's more information: http://java.sun.com/blueprints/corej2eepatterns/Patterns/BusinessDelegate.html http://www.developer.com/java/other/article.php/626001 robert > -Original Message- > From: Adam Hardy [mailto:[EMAIL PROTECTED] > Sent: Tuesday, March 16, 2004 6:26 PM > To: Struts Users Mailing List > Subject: action - delegate - facade > > > I've just been perusing the archive to check out what people have been > saying about struts to EJB interfacing. > > One thing that occurs to me is that the only reason mentioned for having > a business delegate layer between the Actions and the Session Facade is > to allow for loose coupling of the struts-dependent code with the EJB > dependent code. > > How necessary is that? If you choose to drop EJB and go with, say > Hibernate, you would have to modify the interface, whether it is the > Action - Facade interface or the Delegate - Facade interface. > > Or have I missed an important other reason for the existence of the > Delegate layer? > > Adam > -- > struts 1.1 + tomcat 5.0.16 + java 1.4.2 > Linux 2.4.20 Debian > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: action - delegate - facade
Hi Robert and Adam...
Guess I am paranoid or prepared.. :-)
I use nearly the approach Robert described, using a Factory for the
delegatealthough the purpose is not the same..
I use the Delegate as the "web tier view" of the business logic/services in
the system. That becomes important, when different business rules/logic
applies to different modules/plugin.
In my scenario I call the business delegates for business plugins because of
the dynamic plugable nature. Plugins are hosted by a plugin manager (the
factory), and access the plugin interfaces always goes through the plugin
manager.
You get an interface to a plugin (ie. web tier view of a business service),
not an implementation...that's important as you state correctly Robert.
The difference is that I don't care if it is a POJO, EJB, whatever I am
talking to "behing the scenes", I care about HOW the business service is
implemented...
Let me give you an example:
Way through system is:
Action->Plugin->Facade->Entity
Pseudo code for action execute:
AccountManagement plugin =
pluginManager.getPlugin("core.account.management");
What I get here is an interface (AccountManagement) of a business service
plugin. Behind the interface, one specific implementation of it resides.
WHAT implementation to use is decided by the plugin manager. I my scenario
it is based on a customer, which have a certain business role. But it can be
whatever logic to decide which implementation to use.
Now I use the the plugin business service interface from my action
plugin.createAccount("001", "Hans Gruber");
With this one call a specific implementation of the Management interface is
called. What happens behind the scenes is not important from the actions
point of view. Maybe different business rules/logic applies for different
implementations of the AccountManagement.
What actually happens is that the plugin service implementation calls a
facade to fulfil the business action of creating an account.
This approach is highly flexible...You have the possibility of hosting
different customers (with different needs) under the same application
constrcuted using business plugins building blocks.
It also (like other business delegates as you stated Robert) promotes
loosely coupling between the web tier and EJB or whatever tier is behind.
With this clean interface it is very very easy to provide an additonal XML
WebServices interface (maybe though Axis) that makes your business services
accessible from other platforms, systems, whatever...
My few bucks...Anyone has comments...they are welcome...
Regards
Henrik
- Original Message -
From: "Robert Taylor" <[EMAIL PROTECTED]>
To: "Struts Users Mailing List" <[EMAIL PROTECTED]>
Sent: Wednesday, March 17, 2004 2:51 AM
Subject: RE: action - delegate - facade
> Adam, IMHO the Business Delegate pattern abstracts the client from knowing
> your business implementation, whether it be EBJ, JDO, POJO, roll your own.
The
> client interfaces with the Business Delegate and not its implementation.
> For example, if you have an Action (client) interface with the Business
Delegate
> instead of directly with a SessionFacade, then you can change the
underlying implementation
> of the Business Delegate without changing anything in the client.
> If your really paranoid (or prepared), you can use the Abstract Factory
pattern which you could then
> initialize/subclass to create the appropriate Business Delegate
implementations (EJB, JDO, main frame).
>
> Also by using a Business Delegate the client isn't exposed to
implementation details
> such as (if your using EJB) looking up the appropropriate EJB or handling
implementation
> specific exceptions. The Business Delegate becomes a high level
abstraction of the
> business rules raising application level exceptions when error occur to
which the client
> can respond appropriately.
>
> So, you wouldn't necessarily have to modify the Delegate-Facade interface.
The interface
> itself remains unchanged. You have to use a different implementation. That
is where the
> factory comes in. I imagine you could do something like the following:
>
> Properties props = // get initialization properties
>// to initialize factory to return EJB BD
implementations
> BusinessDelegateFactory bdf = BusinessDelegateFactory.init(props);
>
>
> In your client, suppose AccountBD is your BusinessDelegate interface:
>
> BusinessDelegateFactory bdf = BusinessDelegateFactory.getInstance();
> AccountBD accountBD =
(AccountBD)bdf.createBusinessDelegate(AccountBD.BD_NAME);
>
> So you just end up "plugging" in new implementations as needed.
>
> Anyhow, that's my interpretation of the some of the forces behind the
pattern
> and an idea on implementing it.
>
> Here's
Re: action - delegate - facade
In relation to this area it's probably worth tracking JSR 227 - "A Standard Data Binding & Data Access Facility for J2EE" (http://www.jcp.org/en/jsr/detail?id=227) Which provides, in metadata, an abstraction of the business service in terms of collections and operations. Allowing the view & controller layers can be totally agnostic of the actual source of that set of data / logic, be it EJB, a Webservice, LDAP, POJO, TopLink or whatever. You can play with an early version of this in JDeveloper 10g Preview <http://otn.oracle.com/software/products/jdev/index.html> or wait for JDeveloper 10g Production which will be available "real soon". Duncan Robert Taylor wrote: Adam, IMHO the Business Delegate pattern abstracts the client from knowing your business implementation, whether it be EBJ, JDO, POJO, roll your own. The client interfaces with the Business Delegate and not its implementation. For example, if you have an Action (client) interface with the Business Delegate instead of directly with a SessionFacade, then you can change the underlying implementation of the Business Delegate without changing anything in the client. If your really paranoid (or prepared), you can use the Abstract Factory pattern which you could then initialize/subclass to create the appropriate Business Delegate implementations (EJB, JDO, main frame). Also by using a Business Delegate the client isn't exposed to implementation details such as (if your using EJB) looking up the appropropriate EJB or handling implementation specific exceptions. The Business Delegate becomes a high level abstraction of the business rules raising application level exceptions when error occur to which the client can respond appropriately. So, you wouldn't necessarily have to modify the Delegate-Facade interface. The interface itself remains unchanged. You have to use a different implementation. That is where the factory comes in. I imagine you could do something like the following: Properties props = // get initialization properties // to initialize factory to return EJB BD implementations BusinessDelegateFactory bdf = BusinessDelegateFactory.init(props); In your client, suppose AccountBD is your BusinessDelegate interface: BusinessDelegateFactory bdf = BusinessDelegateFactory.getInstance(); AccountBD accountBD = (AccountBD)bdf.createBusinessDelegate(AccountBD.BD_NAME); So you just end up "plugging" in new implementations as needed. Anyhow, that's my interpretation of the some of the forces behind the pattern and an idea on implementing it. Here's more information: http://java.sun.com/blueprints/corej2eepatterns/Patterns/BusinessDelegate.html http://www.developer.com/java/other/article.php/626001 robert -Original Message- From: Adam Hardy [mailto:[EMAIL PROTECTED] Sent: Tuesday, March 16, 2004 6:26 PM To: Struts Users Mailing List Subject: action - delegate - facade I've just been perusing the archive to check out what people have been saying about struts to EJB interfacing. One thing that occurs to me is that the only reason mentioned for having a business delegate layer between the Actions and the Session Facade is to allow for loose coupling of the struts-dependent code with the EJB dependent code. How necessary is that? If you choose to drop EJB and go with, say Hibernate, you would have to modify the interface, whether it is the Action - Facade interface or the Delegate - Facade interface. Or have I missed an important other reason for the existence of the Delegate layer? Adam -- struts 1.1 + tomcat 5.0.16 + java 1.4.2 Linux 2.4.20 Debian - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: action - delegate - facade
I am surprised to see that the xpetstore @ sourceforge has a direct
interface between Actions and the session beans.
The delegate does make sense to me now and I'm going to implement it.
One think I've been wondering is about packaging all the classes. Do you
put the delegate classes and the transfer / value object classes in a
seperate jar file from the action classes, and from the EJBs?
While on the subject, what do you use for value objects? Form beans or
something generated by xdoclet? I've been using an xml schema to
generate my value objects so far (not with EJB) via JAXB, but this isn't
going to work with EJB because the things aren't serializable.
Another question (my last!): what is the best way to handle home
interfaces in the delegate? Do you cache them? Do you treat them like a
logger object or a singleton? Or do you just instantiate them fresh each
call?
Thanks!
Adam
On 03/17/2004 09:22 AM HG wrote:
Hi Robert and Adam...
Guess I am paranoid or prepared.. :-)
I use nearly the approach Robert described, using a Factory for the
delegatealthough the purpose is not the same..
I use the Delegate as the "web tier view" of the business logic/services in
the system. That becomes important, when different business rules/logic
applies to different modules/plugin.
In my scenario I call the business delegates for business plugins because of
the dynamic plugable nature. Plugins are hosted by a plugin manager (the
factory), and access the plugin interfaces always goes through the plugin
manager.
You get an interface to a plugin (ie. web tier view of a business service),
not an implementation...that's important as you state correctly Robert.
The difference is that I don't care if it is a POJO, EJB, whatever I am
talking to "behing the scenes", I care about HOW the business service is
implemented...
Let me give you an example:
Way through system is:
Action->Plugin->Facade->Entity
Pseudo code for action execute:
AccountManagement plugin =
pluginManager.getPlugin("core.account.management");
What I get here is an interface (AccountManagement) of a business service
plugin. Behind the interface, one specific implementation of it resides.
WHAT implementation to use is decided by the plugin manager. I my scenario
it is based on a customer, which have a certain business role. But it can be
whatever logic to decide which implementation to use.
Now I use the the plugin business service interface from my action
plugin.createAccount("001", "Hans Gruber");
With this one call a specific implementation of the Management interface is
called. What happens behind the scenes is not important from the actions
point of view. Maybe different business rules/logic applies for different
implementations of the AccountManagement.
What actually happens is that the plugin service implementation calls a
facade to fulfil the business action of creating an account.
This approach is highly flexible...You have the possibility of hosting
different customers (with different needs) under the same application
constrcuted using business plugins building blocks.
It also (like other business delegates as you stated Robert) promotes
loosely coupling between the web tier and EJB or whatever tier is behind.
With this clean interface it is very very easy to provide an additonal XML
WebServices interface (maybe though Axis) that makes your business services
accessible from other platforms, systems, whatever...
My few bucks...Anyone has comments...they are welcome...
Regards
Henrik
- Original Message -
From: "Robert Taylor" <[EMAIL PROTECTED]>
To: "Struts Users Mailing List" <[EMAIL PROTECTED]>
Sent: Wednesday, March 17, 2004 2:51 AM
Subject: RE: action - delegate - facade
Adam, IMHO the Business Delegate pattern abstracts the client from knowing
your business implementation, whether it be EBJ, JDO, POJO, roll your own.
The
client interfaces with the Business Delegate and not its implementation.
For example, if you have an Action (client) interface with the Business
Delegate
instead of directly with a SessionFacade, then you can change the
underlying implementation
of the Business Delegate without changing anything in the client.
If your really paranoid (or prepared), you can use the Abstract Factory
pattern which you could then
initialize/subclass to create the appropriate Business Delegate
implementations (EJB, JDO, main frame).
Also by using a Business Delegate the client isn't exposed to
implementation details
such as (if your using EJB) looking up the appropropriate EJB or handling
implementation
specific exceptions. The Business Delegate becomes a high level
abstraction of the
business rules raising application level exceptions when error occur to
which the client
can respond appropriately.
So, you wouldn't necessarily have to modify the Delegate-Facade interf
Re: action - delegate - facade
Hi Adam.
Your first question, regarding packaging
I keep that part simple, so I place all value objects in a model package,
say "com.mycompany.myproduct.model". Both the ejb-jar and the web-jat
contain these classes.
Your second question, regarding generation value objects
I use xDoclets facilities to generate value objects. If I need special
services/attributes in the value objects I subclass the one generated by
xDoclet and roll my changes.
Your third question, regarding home lookups.
I use the ServiceLocator pattern from my business delegates(plugins). The
service locator is implemented as a Singleton and contains only Facades. I
have antoher another singleton ServiceLocator for Entities.
Each plugin caches the home of the "Business Services" it uses (ie. the
Facades).
Hope to help...otherwisefeel free to ask.
Best regards
Henrik
- Original Message -
From: "Adam Hardy" <[EMAIL PROTECTED]>
To: "Struts Users Mailing List" <[EMAIL PROTECTED]>
Sent: Wednesday, March 17, 2004 11:01 AM
Subject: Re: action - delegate - facade
> I am surprised to see that the xpetstore @ sourceforge has a direct
> interface between Actions and the session beans.
>
> The delegate does make sense to me now and I'm going to implement it.
>
> One think I've been wondering is about packaging all the classes. Do you
> put the delegate classes and the transfer / value object classes in a
> seperate jar file from the action classes, and from the EJBs?
>
> While on the subject, what do you use for value objects? Form beans or
> something generated by xdoclet? I've been using an xml schema to
> generate my value objects so far (not with EJB) via JAXB, but this isn't
> going to work with EJB because the things aren't serializable.
>
> Another question (my last!): what is the best way to handle home
> interfaces in the delegate? Do you cache them? Do you treat them like a
> logger object or a singleton? Or do you just instantiate them fresh each
> call?
>
>
> Thanks!
> Adam
>
>
> On 03/17/2004 09:22 AM HG wrote:
> > Hi Robert and Adam...
> >
> > Guess I am paranoid or prepared.. :-)
> >
> > I use nearly the approach Robert described, using a Factory for the
> > delegatealthough the purpose is not the same..
> >
> > I use the Delegate as the "web tier view" of the business logic/services
in
> > the system. That becomes important, when different business rules/logic
> > applies to different modules/plugin.
> >
> > In my scenario I call the business delegates for business plugins
because of
> > the dynamic plugable nature. Plugins are hosted by a plugin manager (the
> > factory), and access the plugin interfaces always goes through the
plugin
> > manager.
> >
> > You get an interface to a plugin (ie. web tier view of a business
service),
> > not an implementation...that's important as you state correctly Robert.
> > The difference is that I don't care if it is a POJO, EJB, whatever I am
> > talking to "behing the scenes", I care about HOW the business service is
> > implemented...
> >
> > Let me give you an example:
> >
> > Way through system is:
> >
> > Action->Plugin->Facade->Entity
> >
> > Pseudo code for action execute:
> > AccountManagement plugin =
> > pluginManager.getPlugin("core.account.management");
> >
> > What I get here is an interface (AccountManagement) of a business
service
> > plugin. Behind the interface, one specific implementation of it resides.
> > WHAT implementation to use is decided by the plugin manager. I my
scenario
> > it is based on a customer, which have a certain business role. But it
can be
> > whatever logic to decide which implementation to use.
> >
> > Now I use the the plugin business service interface from my action
> >
> > plugin.createAccount("001", "Hans Gruber");
> >
> > With this one call a specific implementation of the Management interface
is
> > called. What happens behind the scenes is not important from the actions
> > point of view. Maybe different business rules/logic applies for
different
> > implementations of the AccountManagement.
> >
> > What actually happens is that the plugin service implementation calls a
> > facade to fulfil the business action of creating an account.
> >
> > This approach is highly flexible...You have the possibility of hosting
> > different customers (with different needs) under the same application
> > constrcuted using business plugins building blocks.
> >
> > It also (like other business delega
Re: action - delegate - facade
ehh..Correction to third answer...
Actually the plugin caches the reference to the EJB Facade and the Service
Locator caches the home looked up from JNDI...
Is this really safe..?? :-)
- Original Message -
From: "HG" <[EMAIL PROTECTED]>
To: "Struts Users Mailing List" <[EMAIL PROTECTED]>
Sent: Wednesday, March 17, 2004 12:31 PM
Subject: Re: action - delegate - facade
> Hi Adam.
>
> Your first question, regarding packaging
> I keep that part simple, so I place all value objects in a model package,
> say "com.mycompany.myproduct.model". Both the ejb-jar and the web-jat
> contain these classes.
>
> Your second question, regarding generation value objects
> I use xDoclets facilities to generate value objects. If I need special
> services/attributes in the value objects I subclass the one generated by
> xDoclet and roll my changes.
>
> Your third question, regarding home lookups.
> I use the ServiceLocator pattern from my business delegates(plugins). The
> service locator is implemented as a Singleton and contains only Facades. I
> have antoher another singleton ServiceLocator for Entities.
> Each plugin caches the home of the "Business Services" it uses (ie. the
> Facades).
>
> Hope to help...otherwisefeel free to ask.
>
> Best regards
>
> Henrik
>
>
> - Original Message -
> From: "Adam Hardy" <[EMAIL PROTECTED]>
> To: "Struts Users Mailing List" <[EMAIL PROTECTED]>
> Sent: Wednesday, March 17, 2004 11:01 AM
> Subject: Re: action - delegate - facade
>
>
> > I am surprised to see that the xpetstore @ sourceforge has a direct
> > interface between Actions and the session beans.
> >
> > The delegate does make sense to me now and I'm going to implement it.
> >
> > One think I've been wondering is about packaging all the classes. Do you
> > put the delegate classes and the transfer / value object classes in a
> > seperate jar file from the action classes, and from the EJBs?
> >
> > While on the subject, what do you use for value objects? Form beans or
> > something generated by xdoclet? I've been using an xml schema to
> > generate my value objects so far (not with EJB) via JAXB, but this isn't
> > going to work with EJB because the things aren't serializable.
> >
> > Another question (my last!): what is the best way to handle home
> > interfaces in the delegate? Do you cache them? Do you treat them like a
> > logger object or a singleton? Or do you just instantiate them fresh each
> > call?
> >
> >
> > Thanks!
> > Adam
> >
> >
> > On 03/17/2004 09:22 AM HG wrote:
> > > Hi Robert and Adam...
> > >
> > > Guess I am paranoid or prepared.. :-)
> > >
> > > I use nearly the approach Robert described, using a Factory for the
> > > delegatealthough the purpose is not the same..
> > >
> > > I use the Delegate as the "web tier view" of the business
logic/services
> in
> > > the system. That becomes important, when different business
rules/logic
> > > applies to different modules/plugin.
> > >
> > > In my scenario I call the business delegates for business plugins
> because of
> > > the dynamic plugable nature. Plugins are hosted by a plugin manager
(the
> > > factory), and access the plugin interfaces always goes through the
> plugin
> > > manager.
> > >
> > > You get an interface to a plugin (ie. web tier view of a business
> service),
> > > not an implementation...that's important as you state correctly
Robert.
> > > The difference is that I don't care if it is a POJO, EJB, whatever I
am
> > > talking to "behing the scenes", I care about HOW the business service
is
> > > implemented...
> > >
> > > Let me give you an example:
> > >
> > > Way through system is:
> > >
> > > Action->Plugin->Facade->Entity
> > >
> > > Pseudo code for action execute:
> > > AccountManagement plugin =
> > > pluginManager.getPlugin("core.account.management");
> > >
> > > What I get here is an interface (AccountManagement) of a business
> service
> > > plugin. Behind the interface, one specific implementation of it
resides.
> > > WHAT implementation to use is decided by the plugin manager. I my
> scenario
> > > it is based on a customer, which have a certain business role. But it
> can be
> > > whatever logic to decide which implementation to use.
> > >
Re: action - delegate - facade
Is it safe? I really don't know. You'd have to ask someone else or
wait until I've got a couple of years experience with the service
locator pattern, and I'll let you know ;)
but regarding value objects - you use BeanUtils to copy the properties
into the form beans?
On 03/17/2004 12:34 PM HG wrote:
ehh..Correction to third answer...
Actually the plugin caches the reference to the EJB Facade and the Service
Locator caches the home looked up from JNDI...
Is this really safe..?? :-)
- Original Message -
From: "HG" <[EMAIL PROTECTED]>
To: "Struts Users Mailing List" <[EMAIL PROTECTED]>
Sent: Wednesday, March 17, 2004 12:31 PM
Subject: Re: action - delegate - facade
Hi Adam.
Your first question, regarding packaging
I keep that part simple, so I place all value objects in a model package,
say "com.mycompany.myproduct.model". Both the ejb-jar and the web-jat
contain these classes.
Your second question, regarding generation value objects
I use xDoclets facilities to generate value objects. If I need special
services/attributes in the value objects I subclass the one generated by
xDoclet and roll my changes.
Your third question, regarding home lookups.
I use the ServiceLocator pattern from my business delegates(plugins). The
service locator is implemented as a Singleton and contains only Facades. I
have antoher another singleton ServiceLocator for Entities.
Each plugin caches the home of the "Business Services" it uses (ie. the
Facades).
Hope to help...otherwisefeel free to ask.
Best regards
Henrik
- Original Message -
From: "Adam Hardy" <[EMAIL PROTECTED]>
To: "Struts Users Mailing List" <[EMAIL PROTECTED]>
Sent: Wednesday, March 17, 2004 11:01 AM
Subject: Re: action - delegate - facade
I am surprised to see that the xpetstore @ sourceforge has a direct
interface between Actions and the session beans.
The delegate does make sense to me now and I'm going to implement it.
One think I've been wondering is about packaging all the classes. Do you
put the delegate classes and the transfer / value object classes in a
seperate jar file from the action classes, and from the EJBs?
While on the subject, what do you use for value objects? Form beans or
something generated by xdoclet? I've been using an xml schema to
generate my value objects so far (not with EJB) via JAXB, but this isn't
going to work with EJB because the things aren't serializable.
Another question (my last!): what is the best way to handle home
interfaces in the delegate? Do you cache them? Do you treat them like a
logger object or a singleton? Or do you just instantiate them fresh each
call?
Thanks!
Adam
On 03/17/2004 09:22 AM HG wrote:
Hi Robert and Adam...
Guess I am paranoid or prepared.. :-)
I use nearly the approach Robert described, using a Factory for the
delegatealthough the purpose is not the same..
I use the Delegate as the "web tier view" of the business
logic/services
in
the system. That becomes important, when different business
rules/logic
applies to different modules/plugin.
In my scenario I call the business delegates for business plugins
because of
the dynamic plugable nature. Plugins are hosted by a plugin manager
(the
factory), and access the plugin interfaces always goes through the
plugin
manager.
You get an interface to a plugin (ie. web tier view of a business
service),
not an implementation...that's important as you state correctly
Robert.
The difference is that I don't care if it is a POJO, EJB, whatever I
am
talking to "behing the scenes", I care about HOW the business service
is
implemented...
Let me give you an example:
Way through system is:
Action->Plugin->Facade->Entity
Pseudo code for action execute:
AccountManagement plugin =
pluginManager.getPlugin("core.account.management");
What I get here is an interface (AccountManagement) of a business
service
plugin. Behind the interface, one specific implementation of it
resides.
WHAT implementation to use is decided by the plugin manager. I my
scenario
it is based on a customer, which have a certain business role. But it
can be
whatever logic to decide which implementation to use.
Now I use the the plugin business service interface from my action
plugin.createAccount("001", "Hans Gruber");
With this one call a specific implementation of the Management
interface
is
called. What happens behind the scenes is not important from the
actions
point of view. Maybe different business rules/logic applies for
different
implementations of the AccountManagement.
What actually happens is that the plugin service implementation calls
a
facade to fulfil the business action of creating an account.
This approach is highly flexible...You have the possibility of hosting
different customers (with different needs) under the sam
RE: action - delegate - facade
Hi Adam there is a good book on it! http://www.corej2eepatterns.com/Patterns2ndEd/index.htm i use it very often... but more it's german version... :-) however that covers j2ee1.4 cheers, btw. under the sun, there is a code camps, or however they call it for strtus and j2ee_patterns: http://developers.sun.com/events/techdays/codecamps/index.html (third link ;-)) cheers! Matthias -Original Message- From: Adam Hardy [mailto:[EMAIL PROTECTED] Sent: Wednesday, March 17, 2004 2:08 PM To: Struts Users Mailing List Subject: Re: action - delegate - facade Is it safe? I really don't know. You'd have to ask someone else or wait until I've got a couple of years experience with the service locator pattern, and I'll let you know ;) but regarding value objects - you use BeanUtils to copy the properties into the form beans? On 03/17/2004 12:34 PM HG wrote: > ehh..Correction to third answer... > > Actually the plugin caches the reference to the EJB Facade and the > Service Locator caches the home looked up from JNDI... > > Is this really safe..?? :-) > > > - Original Message - > From: "HG" <[EMAIL PROTECTED]> > To: "Struts Users Mailing List" <[EMAIL PROTECTED]> > Sent: Wednesday, March 17, 2004 12:31 PM > Subject: Re: action - delegate - facade > > > >>Hi Adam. >> >>Your first question, regarding packaging >>I keep that part simple, so I place all value objects in a model >>package, say "com.mycompany.myproduct.model". Both the ejb-jar and the >>web-jat contain these classes. >> >>Your second question, regarding generation value objects >>I use xDoclets facilities to generate value objects. If I need special >>services/attributes in the value objects I subclass the one generated >>by xDoclet and roll my changes. >> >>Your third question, regarding home lookups. >>I use the ServiceLocator pattern from my business delegates(plugins). >>The service locator is implemented as a Singleton and contains only >>Facades. I have antoher another singleton ServiceLocator for Entities. >>Each plugin caches the home of the "Business Services" it uses (ie. >>the Facades). >> >>Hope to help...otherwise....feel free to ask. >> >>Best regards >> >>Henrik >> >> >>- Original Message - >>From: "Adam Hardy" <[EMAIL PROTECTED]> >>To: "Struts Users Mailing List" <[EMAIL PROTECTED]> >>Sent: Wednesday, March 17, 2004 11:01 AM >>Subject: Re: action - delegate - facade >> >> >> >>>I am surprised to see that the xpetstore @ sourceforge has a direct >>>interface between Actions and the session beans. >>> >>>The delegate does make sense to me now and I'm going to implement it. >>> >>>One think I've been wondering is about packaging all the classes. Do >>>you put the delegate classes and the transfer / value object classes >>>in a seperate jar file from the action classes, and from the EJBs? >>> >>>While on the subject, what do you use for value objects? Form beans >>>or something generated by xdoclet? I've been using an xml schema to >>>generate my value objects so far (not with EJB) via JAXB, but this >>>isn't going to work with EJB because the things aren't serializable. >>> >>>Another question (my last!): what is the best way to handle home >>>interfaces in the delegate? Do you cache them? Do you treat them like >>>a logger object or a singleton? Or do you just instantiate them fresh >>>each call? >>> >>> >>>Thanks! >>>Adam >>> >>> >>>On 03/17/2004 09:22 AM HG wrote: >>> >>>>Hi Robert and Adam... >>>> >>>>Guess I am paranoid or prepared.. :-) >>>> >>>>I use nearly the approach Robert described, using a Factory for the >>>>delegatealthough the purpose is not the same.. >>>> >>>>I use the Delegate as the "web tier view" of the business > > logic/services > >>in >> >>>>the system. That becomes important, when different business > > rules/logic > >>>>applies to different modules/plugin. >>>> >>>>In my scenario I call the business delegates for business plugins >> >>because of >> >>>>the dynamic plugable nature. Plugins are hosted by a plugin manager > > (the > >>>>factory), and access the plugin interfaces always goes through the >
Re: action - delegate - facade
Hi Adam.. Well, I haven't experienced any problems whatsoever with this approach...so I guess it is safe. Sometimes I use BeanUtils to copy attributes but not very often...in my opinion DTOs (or Value Objects) and the form bean is two totally different concepts..therefore I like to keep them separate and sometimes with different attribute names...Just my way of doing it ..might be silly...I dunno..:-) - Original Message - From: "Adam Hardy" <[EMAIL PROTECTED]> To: "Struts Users Mailing List" <[EMAIL PROTECTED]> Sent: Wednesday, March 17, 2004 2:07 PM Subject: Re: action - delegate - facade > Is it safe? I really don't know. You'd have to ask someone else or > wait until I've got a couple of years experience with the service > locator pattern, and I'll let you know ;) > > but regarding value objects - you use BeanUtils to copy the properties > into the form beans? > > > > On 03/17/2004 12:34 PM HG wrote: > > ehh..Correction to third answer... > > > > Actually the plugin caches the reference to the EJB Facade and the Service > > Locator caches the home looked up from JNDI... > > > > Is this really safe..?? :-) > > > > > > - Original Message - > > From: "HG" <[EMAIL PROTECTED]> > > To: "Struts Users Mailing List" <[EMAIL PROTECTED]> > > Sent: Wednesday, March 17, 2004 12:31 PM > > Subject: Re: action - delegate - facade > > > > > > > >>Hi Adam. > >> > >>Your first question, regarding packaging > >>I keep that part simple, so I place all value objects in a model package, > >>say "com.mycompany.myproduct.model". Both the ejb-jar and the web-jat > >>contain these classes. > >> > >>Your second question, regarding generation value objects > >>I use xDoclets facilities to generate value objects. If I need special > >>services/attributes in the value objects I subclass the one generated by > >>xDoclet and roll my changes. > >> > >>Your third question, regarding home lookups. > >>I use the ServiceLocator pattern from my business delegates(plugins). The > >>service locator is implemented as a Singleton and contains only Facades. I > >>have antoher another singleton ServiceLocator for Entities. > >>Each plugin caches the home of the "Business Services" it uses (ie. the > >>Facades). > >> > >>Hope to help...otherwisefeel free to ask. > >> > >>Best regards > >> > >>Henrik > >> > >> > >>- Original Message - > >>From: "Adam Hardy" <[EMAIL PROTECTED]> > >>To: "Struts Users Mailing List" <[EMAIL PROTECTED]> > >>Sent: Wednesday, March 17, 2004 11:01 AM > >>Subject: Re: action - delegate - facade > >> > >> > >> > >>>I am surprised to see that the xpetstore @ sourceforge has a direct > >>>interface between Actions and the session beans. > >>> > >>>The delegate does make sense to me now and I'm going to implement it. > >>> > >>>One think I've been wondering is about packaging all the classes. Do you > >>>put the delegate classes and the transfer / value object classes in a > >>>seperate jar file from the action classes, and from the EJBs? > >>> > >>>While on the subject, what do you use for value objects? Form beans or > >>>something generated by xdoclet? I've been using an xml schema to > >>>generate my value objects so far (not with EJB) via JAXB, but this isn't > >>>going to work with EJB because the things aren't serializable. > >>> > >>>Another question (my last!): what is the best way to handle home > >>>interfaces in the delegate? Do you cache them? Do you treat them like a > >>>logger object or a singleton? Or do you just instantiate them fresh each > >>>call? > >>> > >>> > >>>Thanks! > >>>Adam > >>> > >>> > >>>On 03/17/2004 09:22 AM HG wrote: > >>> > >>>>Hi Robert and Adam... > >>>> > >>>>Guess I am paranoid or prepared.. :-) > >>>> > >>>>I use nearly the approach Robert described, using a Factory for the > >>>>delegatealthough the purpose is not the same.. > >>>> > >>>>I use the Delegate as the "web tier view" of the business > > > > logic/s
Re: action - delegate - facade
Thanks Matthias. The codecamp looks like just the right thing.
Adam
On 03/17/2004 02:17 PM Matthias Wessendorf wrote:
Hi Adam
there is a good book on it!
http://www.corej2eepatterns.com/Patterns2ndEd/index.htm i use it very
often... but more it's german version... :-) however that covers
j2ee1.4 cheers,
btw. under the sun, there is a code camps, or however they call it
for strtus and j2ee_patterns:
http://developers.sun.com/events/techdays/codecamps/index.html (third
link ;-))
cheers! Matthias
-Original Message- From: Adam Hardy
[mailto:[EMAIL PROTECTED] Sent: Wednesday, March 17,
2004 2:08 PM To: Struts Users Mailing List Subject: Re: action -
delegate - facade
Is it safe? I really don't know. You'd have to ask someone else
or wait until I've got a couple of years experience with the service
locator pattern, and I'll let you know ;)
but regarding value objects - you use BeanUtils to copy the
properties into the form beans?
On 03/17/2004 12:34 PM HG wrote:
ehh..Correction to third answer...
Actually the plugin caches the reference to the EJB Facade and the
Service Locator caches the home looked up from JNDI...
Is this really safe..?? :-)
- Original Message - From: "HG"
<[EMAIL PROTECTED]> To: "Struts Users Mailing List"
<[EMAIL PROTECTED]> Sent: Wednesday, March 17, 2004
12:31 PM Subject: Re: action - delegate - facade
Hi Adam.
Your first question, regarding packaging I keep that part simple,
so I place all value objects in a model package, say
"com.mycompany.myproduct.model". Both the ejb-jar and the
web-jat contain these classes.
Your second question, regarding generation value objects I use
xDoclets facilities to generate value objects. If I need special
services/attributes in the value objects I subclass the one
generated by xDoclet and roll my changes.
Your third question, regarding home lookups. I use the
ServiceLocator pattern from my business delegates(plugins). The
service locator is implemented as a Singleton and contains only
Facades. I have antoher another singleton ServiceLocator for
Entities.
Each plugin caches the home of the "Business Services" it uses
(ie. the Facades).
Hope to help...otherwisefeel free to ask.
Best regards
Henrik
- Original Message - From: "Adam Hardy"
<[EMAIL PROTECTED]> To: "Struts Users Mailing
List" <[EMAIL PROTECTED]> Sent: Wednesday, March 17,
2004 11:01 AM Subject: Re: action - delegate - facade
I am surprised to see that the xpetstore @ sourceforge has a
direct interface between Actions and the session beans.
The delegate does make sense to me now and I'm going to
implement it.
One think I've been wondering is about packaging all the
classes. Do you put the delegate classes and the transfer /
value object classes in a seperate jar file from the action
classes, and from the EJBs?
While on the subject, what do you use for value objects? Form
beans or something generated by xdoclet? I've been using an xml
schema to generate my value objects so far (not with EJB) via
JAXB, but this isn't going to work with EJB because the things
aren't serializable.
Another question (my last!): what is the best way to handle
home interfaces in the delegate? Do you cache them? Do you
treat them like
a logger object or a singleton? Or do you just instantiate them
fresh
each call?
Thanks! Adam
On 03/17/2004 09:22 AM HG wrote:
Hi Robert and Adam...
Guess I am paranoid or prepared.. :-)
I use nearly the approach Robert described, using a Factory
for the delegatealthough the purpose is not the same..
I use the Delegate as the "web tier view" of the business
logic/services
in
the system. That becomes important, when different business
rules/logic
applies to different modules/plugin.
In my scenario I call the business delegates for business
plugins
because of
the dynamic plugable nature. Plugins are hosted by a plugin
manager
(the
factory), and access the plugin interfaces always goes
through the
plugin
manager.
You get an interface to a plugin (ie. web tier view of a
business
service),
not an implementation...that's important as you state
correctly
Robert.
The difference is that I don't care if it is a POJO, EJB,
whatever I
am
talking to "behing the scenes", I care about HOW the business
service
is
implemented...
Let me give you an example:
Way through system is:
Action->Plugin->Facade->Entity
Pseudo code for action execute: AccountManagement plugin =
pluginManager.getPlugin("core.account.management");
What I get here is an interface (AccountManagement) of a
business
service
plugin. Behind the interface, one specific implementation of
it
resides.
WHAT implementation to use is decided by the plugin manager.
I my
scenario
it is based on a customer, which have a certain business
role. But it
can be
Re: action - delegate - facade
On 17/03/2004 13:33, "HG" <[EMAIL PROTECTED]> wrote:
> Hi Adam..
>
> Well, I haven't experienced any problems whatsoever with this approach...so
> I guess it is safe.
>
> Sometimes I use BeanUtils to copy attributes but not very often...in my
> opinion DTOs (or Value Objects) and the form bean is two totally different
> concepts..therefore I like to keep them separate and sometimes with
> different attribute names...Just my way of doing it ..might be silly...I
> dunno..:-)
>
(sorry to jump in to the conversation)
I have been doing this but using a xml configuration file, using a Struts
plugin. It falls on something like this:
http://www.04web.com/dtd/horizon-config_1_0.dtd";>
(similar to struts-config)
I did this because I found it a bit confusing mixing bean attributes to
retrieve html form data and attributes to deliver the intended presentation.
I use a "view" factory to retrieve the bean definitions and then do
something like:
view.set("property", object); (I extended the DynaBean and implement the
Map interface to achieve this - much simpler and JSTL friendly)
...you could also use BeanUtils for setting the properties.
A simple module aware configuration:
When I send the request I usually send a "view". If aa prepopulated html
form is to be presented I send a "view" and a form bean.
Voila :)
Pedro Salgado
(http://www.04web.com/)
>
> - Original Message -
> From: "Adam Hardy" <[EMAIL PROTECTED]>
> To: "Struts Users Mailing List" <[EMAIL PROTECTED]>
> Sent: Wednesday, March 17, 2004 2:07 PM
> Subject: Re: action - delegate - facade
>
>
>> Is it safe? I really don't know. You'd have to ask someone else or
>> wait until I've got a couple of years experience with the service
>> locator pattern, and I'll let you know ;)
>>
>> but regarding value objects - you use BeanUtils to copy the properties
>> into the form beans?
>>
>>
>>
>> On 03/17/2004 12:34 PM HG wrote:
>>> ehh..Correction to third answer...
>>>
>>> Actually the plugin caches the reference to the EJB Facade and the
> Service
>>> Locator caches the home looked up from JNDI...
>>>
>>> Is this really safe..?? :-)
>>>
>>>
>>> - Original Message -
>>> From: "HG" <[EMAIL PROTECTED]>
>>> To: "Struts Users Mailing List" <[EMAIL PROTECTED]>
>>> Sent: Wednesday, March 17, 2004 12:31 PM
>>> Subject: Re: action - delegate - facade
>>>
>>>
>>>
>>>> Hi Adam.
>>>>
>>>> Your first question, regarding packaging
>>>> I keep that part simple, so I place all value objects in a model
> package,
>>>> say "com.mycompany.myproduct.model". Both the ejb-jar and the web-jat
>>>> contain these classes.
>>>>
>>>> Your second question, regarding generation value objects
>>>> I use xDoclets facilities to generate value objects. If I need special
>>>> services/attributes in the value objects I subclass the one generated by
>>>> xDoclet and roll my changes.
>>>>
>>>> Your third question, regarding home lookups.
>>>> I use the ServiceLocator pattern from my business delegates(plugins).
> The
>>>> service locator is implemented as a Singleton and contains only Facades.
> I
>>>> have antoher another singleton ServiceLocator for Entities.
>>>> Each plugin caches the home of the "Business Services" it uses (ie. the
>>>> Facades).
>>>>
>>>> Hope to help...otherwisefeel free to ask.
>>>>
>>>> Best regards
>>>>
>>>> Henrik
>>>>
>>>>
>>>> - Original Message -
>>>> From: "Adam Hardy" <[EMAIL PROTECTED]>
>>>> To: "Struts Users Mailing List" <[EMAIL PROTECTED]>
>>>> Sent: Wednesday, March 17, 2004 11:01 AM
>>>> Subject: Re: action - delegate - facade
>>>>
>>>>
>>>>
>>>>> I am surprised to see that the xpetstore @ sourceforge has a direct
>>>>> interface between Actions and the session beans.
>>>>>
>>>>> The delegate does make sense to me now and I'm going to implement it.
>>>>>
>>>>> One think I've been wondering is about packaging all the classes.
Re: action - delegate - facade
The advantage of this approach, the way I see it, is that it allows you
to declare all your 'views' or 'transfer objects' in xml, and have them
strongly typed (as opposed to formbeans) - and that it works well with
BeanUtils.copyProperties.
Are there any disadvantages at the back-end because of the map-backed
nature? I mean in the EJB layer?
I have been doing this but using a xml configuration file, using a Struts
plugin. It falls on something like this:
http://www.04web.com/dtd/horizon-config_1_0.dtd";>
(similar to struts-config)
I did this because I found it a bit confusing mixing bean attributes to
retrieve html form data and attributes to deliver the intended presentation.
I use a "view" factory to retrieve the bean definitions and then do
something like:
view.set("property", object); (I extended the DynaBean and implement the
Map interface to achieve this - much simpler and JSTL friendly)
...you could also use BeanUtils for setting the properties.
A simple module aware configuration:
When I send the request I usually send a "view". If aa prepopulated html
form is to be presented I send a "view" and a form bean.
Voila :)
Pedro Salgado
(http://www.04web.com/)
- Original Message -
From: "Adam Hardy" <[EMAIL PROTECTED]>
To: "Struts Users Mailing List" <[EMAIL PROTECTED]>
Sent: Wednesday, March 17, 2004 2:07 PM
Subject: Re: action - delegate - facade
Is it safe? I really don't know. You'd have to ask someone else or
wait until I've got a couple of years experience with the service
locator pattern, and I'll let you know ;)
but regarding value objects - you use BeanUtils to copy the properties
into the form beans?
On 03/17/2004 12:34 PM HG wrote:
ehh..Correction to third answer...
Actually the plugin caches the reference to the EJB Facade and the
Service
Locator caches the home looked up from JNDI...
Is this really safe..?? :-)
- Original Message -
From: "HG" <[EMAIL PROTECTED]>
To: "Struts Users Mailing List" <[EMAIL PROTECTED]>
Sent: Wednesday, March 17, 2004 12:31 PM
Subject: Re: action - delegate - facade
Hi Adam.
Your first question, regarding packaging
I keep that part simple, so I place all value objects in a model
package,
say "com.mycompany.myproduct.model". Both the ejb-jar and the web-jat
contain these classes.
Your second question, regarding generation value objects
I use xDoclets facilities to generate value objects. If I need special
services/attributes in the value objects I subclass the one generated by
xDoclet and roll my changes.
Your third question, regarding home lookups.
I use the ServiceLocator pattern from my business delegates(plugins).
The
service locator is implemented as a Singleton and contains only Facades.
I
have antoher another singleton ServiceLocator for Entities.
Each plugin caches the home of the "Business Services" it uses (ie. the
Facades).
Hope to help...otherwisefeel free to ask.
Best regards
Henrik
----- Original Message -
From: "Adam Hardy" <[EMAIL PROTECTED]>
To: "Struts Users Mailing List" <[EMAIL PROTECTED]>
Sent: Wednesday, March 17, 2004 11:01 AM
Subject: Re: action - delegate - facade
I am surprised to see that the xpetstore @ sourceforge has a direct
interface between Actions and the session beans.
The delegate does make sense to me now and I'm going to implement it.
One think I've been wondering is about packaging all the classes. Do
you
put the delegate classes and the transfer / value object classes in a
seperate jar file from the action classes, and from the EJBs?
While on the subject, what do you use for value objects? Form beans or
something generated by xdoclet? I've been using an xml schema to
generate my value objects so far (not with EJB) via JAXB, but this
isn't
going to work with EJB because the things aren't serializable.
Another question (my last!): what is the best way to handle home
interfaces in the delegate? Do you cache them? Do you treat them like a
logger object or a singleton? Or do you just instantiate them fresh
each
call?
Thanks!
Adam
On 03/17/2004 09:22 AM HG wrote:
Hi Robert and Adam...
Guess I am paranoid or prepared.. :-)
I use nearly the approach Robert described, using a Factory for the
delegatealthough the purpose is not the same..
I use the Delegate as the "web tier view" of the business
logic/services
in
the system. That becomes important, when different business
rules/logic
applies to different modules/plugin.
In my scenario I call the business delegates for business plugins
because of
the dynamic plugable nature. Plugins are hosted by a plugin manager
(the
factory), and access the plugin interfaces always goes
RE: action - delegate - facade
Actually this is a pattern mentioned in "EJB Design Patterns - Advanced Patterns
Processes and Idioms"
called Data Transfer HashMap. You can download the pdf from TheServerSide.com. It's a
pretty good read.
The book goes into detail on the pros and cons of this pattern.
http://www.theserverside.com/books/wiley/EJBDesignPatterns/downloads/ejbdesignpatterns.pdf
robert
> -Original Message-
> From: Adam Hardy [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, March 17, 2004 4:00 PM
> To: Struts Users Mailing List
> Subject: Re: action - delegate - facade
>
>
> The advantage of this approach, the way I see it, is that it allows you
> to declare all your 'views' or 'transfer objects' in xml, and have them
> strongly typed (as opposed to formbeans) - and that it works well with
> BeanUtils.copyProperties.
>
> Are there any disadvantages at the back-end because of the map-backed
> nature? I mean in the EJB layer?
>
>
> > I have been doing this but using a xml configuration file, using a Struts
> > plugin. It falls on something like this:
> >
> >
> > > "http://www.04web.com/dtd/horizon-config_1_0.dtd";>
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > (similar to struts-config)
> >
> > I did this because I found it a bit confusing mixing bean attributes to
> > retrieve html form data and attributes to deliver the intended presentation.
> >
> > I use a "view" factory to retrieve the bean definitions and then do
> > something like:
> >
> > view.set("property", object); (I extended the DynaBean and implement the
> > Map interface to achieve this - much simpler and JSTL friendly)
> >
> > ...you could also use BeanUtils for setting the properties.
> >
> >
> > A simple module aware configuration:
> >
> >
> >
> >
> >
> > > value="/WEB-INF/horizon-config.xml"/>
> >
> >
> >
> >
> >
> >
> >
> > When I send the request I usually send a "view". If aa prepopulated html
> > form is to be presented I send a "view" and a form bean.
> >
> > Voila :)
> >
> > Pedro Salgado
> > (http://www.04web.com/)
> >
> >
> >>- Original Message -
> >>From: "Adam Hardy" <[EMAIL PROTECTED]>
> >>To: "Struts Users Mailing List" <[EMAIL PROTECTED]>
> >>Sent: Wednesday, March 17, 2004 2:07 PM
> >>Subject: Re: action - delegate - facade
> >>
> >>
> >>
> >>>Is it safe? I really don't know. You'd have to ask someone else or
> >>>wait until I've got a couple of years experience with the service
> >>>locator pattern, and I'll let you know ;)
> >>>
> >>>but regarding value objects - you use BeanUtils to copy the properties
> >>>into the form beans?
> >>>
> >>>
> >>>
> >>>On 03/17/2004 12:34 PM HG wrote:
> >>>
> >>>>ehh..Correction to third answer...
> >>>>
> >>>>Actually the plugin caches the reference to the EJB Facade and the
> >>
> >>Service
> >>
> >>>>Locator caches the home looked up from JNDI...
> >>>>
> >>>>Is this really safe..?? :-)
> >>>>
> >>>>
> >>>>- Original Message -
> >>>>From: "HG" <[EMAIL PROTECTED]>
> >>>>To: "Struts Users Mailing List" <[EMAIL PROTECTED]>
> >>>>Sent: Wednesday, March 17, 2004 12:31 PM
> >>>>Subject: Re: action - delegate - facade
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>>Hi Adam.
> >>>>>
> >>>>>Your first question, regarding packaging
> >>>>>I keep that part simple, so I place all value objects in a model
> >>
> >>package,
> >>
> >>>>>say "com.mycompany.myproduct.model". Both the ejb-jar and the web-jat
> >>>>>contain these classes.
> >>>>>
> >>>>>Your second question, regarding generation value objects
> >>>>>I use xDoclets facilities to generate value objects. If I need special
> >>>>>services/attributes in the value objects I subclass the one generated b
RE: action - delegate - facade
> Actually this is a pattern mentioned in "EJB Design Patterns - Advanced > Patterns Processes and Idioms" called Data Transfer HashMap. You can > download the pdf from TheServerSide.com. It's a pretty good read. The > book goes into detail on the pros and cons of this pattern. > Well... it wasn't my intention to implement a software pattern :) (I am kidding :) form-beans does the same job - I think - but mixes form input data with form build data - again, feel free to criticize, afterall I am still new with Struts). We already discussed this... but here goes for the rest of the mailing list: - It surely saved me some time (I dont have to define on one XML file the beans I need and after that execute something to automatically generate the java beans - you have to be more carefull though, since you may only encounter some bugs on runtime... unless you use strutstestcase/junit) - made a great work decoupling the presentation from business logic (just like with form-beans) - I dont get confused about what is the user input data and what is the data to help build the user form - it also had another side effect: much less lines for xml configuration file... but more files per application (I can live with this :) ) - it seems easier to reuse "view-beans"/"form-beans" when they are decoupled... but i will need more time/experience to support this Thank you for the document. I will read it very carefully and see if there is another challenge waiting outside this framework. Pedro Salgado > http://www.theserverside.com/books/wiley/EJBDesignPatterns/downloads/ejbdesignpatterns.pdf > > > robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: action - delegate - facade
Great book. Thanks for the link. I think I need more knowledge of xdoclet before I make my mind up though. This offers alot to mull over. Plus I'm also quite keen to use faster, quicker patterns. I use dynaactionforms in struts almost exclusively and regarding this Data Transfer Hashmap, it irritates me that the data must be transferred out of one hashmap into another. In fact it would be ideal to be able to transfer the data in the dynaactionform right down the line to the entity bean. The data elements of each form are primarily defined in the struts-config.xml, so I can't see a clean way of telling the entity bean (or any other object) how to get the data out. On 03/17/2004 11:33 PM [EMAIL PROTECTED] wrote: Actually this is a pattern mentioned in "EJB Design Patterns - Advanced Patterns Processes and Idioms" called Data Transfer HashMap. You can download the pdf from TheServerSide.com. It's a pretty good read. The book goes into detail on the pros and cons of this pattern. Well... it wasn't my intention to implement a software pattern :) (I am kidding :) form-beans does the same job - I think - but mixes form input data with form build data - again, feel free to criticize, afterall I am still new with Struts). We already discussed this... but here goes for the rest of the mailing list: - It surely saved me some time (I dont have to define on one XML file the beans I need and after that execute something to automatically generate the java beans - you have to be more carefull though, since you may only encounter some bugs on runtime... unless you use strutstestcase/junit) - made a great work decoupling the presentation from business logic (just like with form-beans) - I dont get confused about what is the user input data and what is the data to help build the user form - it also had another side effect: much less lines for xml configuration file... but more files per application (I can live with this :) ) - it seems easier to reuse "view-beans"/"form-beans" when they are decoupled... but i will need more time/experience to support this Thank you for the document. I will read it very carefully and see if there is another challenge waiting outside this framework. Pedro Salgado http://www.theserverside.com/books/wiley/EJBDesignPatterns/downloads/ejbdesignpatterns.pdf robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- struts 1.1 + tomcat 5.0.16 + java 1.4.2 Linux 2.4.20 Debian - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: action - delegate - facade
Adam, its frowned upon to pass a web tier object (ActionForm) into the business tier. I believe a widely used technique is to use BeanUtils to copy the properties from the ActionForm to a DTO (a Domain Object) which can be passed to the business tier. robert > -Original Message- > From: Adam Hardy [mailto:[EMAIL PROTECTED] > Sent: Wednesday, March 17, 2004 5:57 PM > To: Struts Users Mailing List > Subject: Re: action - delegate - facade > > > Great book. Thanks for the link. > > I think I need more knowledge of xdoclet before I make my mind up > though. This offers alot to mull over. Plus I'm also quite keen to use > faster, quicker patterns. > > I use dynaactionforms in struts almost exclusively and regarding this > Data Transfer Hashmap, it irritates me that the data must be transferred > out of one hashmap into another. > > In fact it would be ideal to be able to transfer the data in the > dynaactionform right down the line to the entity bean. > > The data elements of each form are primarily defined in the > struts-config.xml, so I can't see a clean way of telling the entity bean > (or any other object) how to get the data out. > > > > > On 03/17/2004 11:33 PM [EMAIL PROTECTED] wrote: > >>Actually this is a pattern mentioned in "EJB Design Patterns - Advanced > >>Patterns Processes and Idioms" called Data Transfer HashMap. You can > >>download the pdf from TheServerSide.com. It's a pretty good read. The > >>book goes into detail on the pros and cons of this pattern. > >> > > > > > > Well... it wasn't my intention to implement a software pattern :) (I am > > kidding :) form-beans does the same job - I think - but mixes form input > > data with form build data - again, feel free to criticize, afterall I am > > still new with Struts). > > > > > > We already discussed this... but here goes for the rest of the mailing > > list: > > > > - It surely saved me some time > > (I dont have to define on one XML file the beans I need and after that > > execute something to automatically generate the java beans - you have to > > be more carefull though, since you may only encounter some bugs on > > runtime... unless you use strutstestcase/junit) > > > > - made a great work decoupling the presentation from business logic > > (just like with form-beans) > > > > - I dont get confused about what is the user input data and what is the > > data to help build the user form > > > > - it also had another side effect: much less lines for xml configuration > > file... but more files per application (I can live with this :) ) > > > > - it seems easier to reuse "view-beans"/"form-beans" when they are > > decoupled... but i will need more time/experience to support this > > > > > > Thank you for the document. I will read it very carefully and see if > > there is another challenge waiting outside this framework. > > > > Pedro Salgado > > > > > >>http://www.theserverside.com/books/wiley/EJBDesignPatterns/downloads/ejbdesignpatterns.pdf > >> > >> > >>robert > > > > > > > > > > > > - > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > -- > struts 1.1 + tomcat 5.0.16 + java 1.4.2 > Linux 2.4.20 Debian > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: action - delegate - facade
OK, I was vaguely aware of that, presumably because it couples the EJB layer to Struts when you code against an ActionForm. However that could easily be remedied because the Action can call DynaActionForm.getMap() and pass on the hashmap heart of the DynaActionForm. It still leaves though the problem that the EJB knows nothing about what is in those hashmaps. Plus it must type-cast all the values. (Assuming as well that all the validation has been done if this was a DynaValidatorActionForm) It would be interesting challenge, if I didn't have the suspicion that the whole of the Struts community would still frown on it. Adam On 03/18/2004 12:20 AM Robert Taylor wrote: Adam, its frowned upon to pass a web tier object (ActionForm) into the business tier. I believe a widely used technique is to use BeanUtils to copy the properties from the ActionForm to a DTO (a Domain Object) which can be passed to the business tier. robert -Original Message- From: Adam Hardy [mailto:[EMAIL PROTECTED] Sent: Wednesday, March 17, 2004 5:57 PM To: Struts Users Mailing List Subject: Re: action - delegate - facade Great book. Thanks for the link. I think I need more knowledge of xdoclet before I make my mind up though. This offers alot to mull over. Plus I'm also quite keen to use faster, quicker patterns. I use dynaactionforms in struts almost exclusively and regarding this Data Transfer Hashmap, it irritates me that the data must be transferred out of one hashmap into another. In fact it would be ideal to be able to transfer the data in the dynaactionform right down the line to the entity bean. The data elements of each form are primarily defined in the struts-config.xml, so I can't see a clean way of telling the entity bean (or any other object) how to get the data out. On 03/17/2004 11:33 PM [EMAIL PROTECTED] wrote: Actually this is a pattern mentioned in "EJB Design Patterns - Advanced Patterns Processes and Idioms" called Data Transfer HashMap. You can download the pdf from TheServerSide.com. It's a pretty good read. The book goes into detail on the pros and cons of this pattern. Well... it wasn't my intention to implement a software pattern :) (I am kidding :) form-beans does the same job - I think - but mixes form input data with form build data - again, feel free to criticize, afterall I am still new with Struts). We already discussed this... but here goes for the rest of the mailing list: - It surely saved me some time (I dont have to define on one XML file the beans I need and after that execute something to automatically generate the java beans - you have to be more carefull though, since you may only encounter some bugs on runtime... unless you use strutstestcase/junit) - made a great work decoupling the presentation from business logic (just like with form-beans) - I dont get confused about what is the user input data and what is the data to help build the user form - it also had another side effect: much less lines for xml configuration file... but more files per application (I can live with this :) ) - it seems easier to reuse "view-beans"/"form-beans" when they are decoupled... but i will need more time/experience to support this Thank you for the document. I will read it very carefully and see if there is another challenge waiting outside this framework. Pedro Salgado http://www.theserverside.com/books/wiley/EJBDesignPatterns/downloads/ejbdesignpatterns.pdf robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- struts 1.1 + tomcat 5.0.16 + java 1.4.2 Linux 2.4.20 Debian - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- struts 1.1 + tomcat 5.0.16 + java 1.4.2 Linux 2.4.20 Debian - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: action - delegate - facade
What about when simply displaying data on a page? Do developers typically copy data out of the domain object just to display it? (As opposed to using it w/ a form.) The only issue I see is that you may end up introducing view helper methods to your model beans. Nick Robert Taylor wrote: Adam, its frowned upon to pass a web tier object (ActionForm) into the business tier. I believe a widely used technique is to use BeanUtils to copy the properties from the ActionForm to a DTO (a Domain Object) which can be passed to the business tier. robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: action - delegate - facade
Well, I would say it depends. If I had a DTO ( a domain object) which had all the fields I needed to display...including types like int, Date, boolean, etc... I would probably just pass that along to the form bean and let view helpers like the Struts tags or JSTL render the contents. With JSTL you can format Dates and numbers. I believe those tags leverage the java.text.* package for formatting data. If I needed to perform some specialized formatting which could not be done by view helpers then I may just convert the necessary fields to Strings (maybe using BeanUtils) format them, and populate my ActionForm. If the view I needed of the data was not encapsulated in a single DTO, then you could retrieve multiple DTO objects and rendered them as described above or use a pattern described as Transfer Object Assembler which builds a custom DTO or a collection of customer DTO objects which you could pass along to the ActionForm. You can read more about Transfer Object Assembler here: http://java.sun.com/blueprints/corej2eepatterns/Patterns/TransferObjectAssembler.html robert > -Original Message- > From: Nick Wesselman [mailto:[EMAIL PROTECTED] > Sent: Wednesday, March 17, 2004 6:28 PM > To: Struts Users Mailing List > Subject: Re: action - delegate - facade > > > What about when simply displaying data on a page? Do developers > typically copy data out of the domain object just to display it? (As > opposed to using it w/ a form.) > > The only issue I see is that you may end up introducing view helper > methods to your model beans. > > Nick > > Robert Taylor wrote: > > >Adam, its frowned upon to pass a web tier object (ActionForm) into the business > >tier. I believe a widely used technique is to use BeanUtils to copy the properties > >from the ActionForm to a DTO (a Domain Object) which can be passed to the > >business tier. > > > >robert > > > > > > > > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: action - delegate - facade
Downside is though, trying to cram string request parameters into your DTO in your form before you validate them. Causes ugly exception messages on the browser. On 03/18/2004 02:25 AM Robert Taylor wrote: Well, I would say it depends. If I had a DTO ( a domain object) which had all the fields I needed to display...including types like int, Date, boolean, etc... I would probably just pass that along to the form bean and let view helpers like the Struts tags or JSTL render the contents. With JSTL you can format Dates and numbers. I believe those tags leverage the java.text.* package for formatting data. If I needed to perform some specialized formatting which could not be done by view helpers then I may just convert the necessary fields to Strings (maybe using BeanUtils) format them, and populate my ActionForm. If the view I needed of the data was not encapsulated in a single DTO, then you could retrieve multiple DTO objects and rendered them as described above or use a pattern described as Transfer Object Assembler which builds a custom DTO or a collection of customer DTO objects which you could pass along to the ActionForm. You can read more about Transfer Object Assembler here: http://java.sun.com/blueprints/corej2eepatterns/Patterns/TransferObjectAssembler.html robert -Original Message- From: Nick Wesselman [mailto:[EMAIL PROTECTED] Sent: Wednesday, March 17, 2004 6:28 PM To: Struts Users Mailing List Subject: Re: action - delegate - facade What about when simply displaying data on a page? Do developers typically copy data out of the domain object just to display it? (As opposed to using it w/ a form.) The only issue I see is that you may end up introducing view helper methods to your model beans. Nick Robert Taylor wrote: Adam, its frowned upon to pass a web tier object (ActionForm) into the business tier. I believe a widely used technique is to use BeanUtils to copy the properties from the ActionForm to a DTO (a Domain Object) which can be passed to the business tier. robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- struts 1.1 + tomcat 5.0.16 + java 1.4.2 Linux 2.4.20 Debian - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: action - delegate - facade
Adam, I think Nick was just asking about the trip from the server to the client, not from the client to the server. As already discussed, the method for transfering user input to the business tier would be to copy the values from the action form to the appropriate DTO's using BeanUtils or some other method. robert > -Original Message- > From: Adam Hardy [mailto:[EMAIL PROTECTED] > Sent: Thursday, March 18, 2004 4:57 AM > To: Struts Users Mailing List > Subject: Re: action - delegate - facade > > > Downside is though, trying to cram string request parameters into your > DTO in your form before you validate them. Causes ugly exception > messages on the browser. > > On 03/18/2004 02:25 AM Robert Taylor wrote: > > Well, I would say it depends. If I had a DTO ( a domain object) which had all the > > fields > > I needed to display...including types like int, Date, boolean, etc... I would > > probably just > > pass that along to the form bean and let view helpers like the Struts tags or JSTL > > render > > the contents. With JSTL you can format Dates and numbers. I believe those tags > > leverage the > > java.text.* package for formatting data. > > > > If I needed to perform some specialized formatting which could not be done by > > view helpers then I may just convert the necessary fields to Strings (maybe using > > BeanUtils) > > format them, and populate my ActionForm. > > > > If the view I needed of the data was not encapsulated in a single DTO, then > > you could retrieve multiple DTO objects and rendered them as described above or > > use a pattern > > described as Transfer Object Assembler which builds a custom DTO or a collection > > of customer DTO > > objects which you could pass along to the ActionForm. > > > > You can read more about Transfer Object Assembler here: > > http://java.sun.com/blueprints/corej2eepatterns/Patterns/TransferObjectAssembler.html > > > > robert > > > > > >>-Original Message- > >>From: Nick Wesselman [mailto:[EMAIL PROTECTED] > >>Sent: Wednesday, March 17, 2004 6:28 PM > >>To: Struts Users Mailing List > >>Subject: Re: action - delegate - facade > >> > >> > >>What about when simply displaying data on a page? Do developers > >>typically copy data out of the domain object just to display it? (As > >>opposed to using it w/ a form.) > >> > >>The only issue I see is that you may end up introducing view helper > >>methods to your model beans. > >> > >>Nick > >> > >>Robert Taylor wrote: > >> > >> > >>>Adam, its frowned upon to pass a web tier object (ActionForm) into the > >>>business > >>>tier. I believe a widely used technique is to use BeanUtils to copy the properties > >> > >>>from the ActionForm to a DTO (a Domain Object) which can be passed to the > >> > >>>business tier. > >>> > >>>robert > >>> > >>> > >>> > >> > >> > >> > >>- > >>To unsubscribe, e-mail: [EMAIL PROTECTED] > >>For additional commands, e-mail: [EMAIL PROTECTED] > >> > > > > > > - > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > -- > struts 1.1 + tomcat 5.0.16 + java 1.4.2 > Linux 2.4.20 Debian > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
