struts-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Adam Hardy <ahardy.str...@cyberspaceroad.com>
Subject Re: action - delegate - facade
Date Wed, 17 Mar 2004 20:59:40 GMT
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:
> 
> <?xml version='1.0' encoding='utf-8'?>
> <!DOCTYPE views PUBLIC "-//04Web//DTD Horizon Configuration 1.0//EN"
>     "http://www.04web.com/dtd/horizon-config_1_0.dtd">
> <views>
> 
>     <view name="usersView">
>         <dyna-property property="users"      type="java.util.Collection"/>
>         <dyna-property property="flag"       type="java.lang.Boolean"/>
>     </view>
> 
> </views>
> 
>  (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:
> 
>     <!-- HORIZON PLUGIN -->
> 
>     <plug-in className="com.ohforweb.horizon.HorizonPlugin">
> 
>         <set-property property="config-files"
> value="/WEB-INF/horizon-config.xml"/>
> 
>         <set-property property="parser-validate" value="true"/>
> 
>         <set-property property="module-aware" value="true"/>
> 
>     </plug-in>
> 
>   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" <ahardy.struts@cyberspaceroad.com>
>>To: "Struts Users Mailing List" <struts-user@jakarta.apache.org>
>>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" <struts@nospam.websolver.dk>
>>>>To: "Struts Users Mailing List" <struts-user@jakarta.apache.org>
>>>>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" <ahardy.struts@cyberspaceroad.com>
>>>>>To: "Struts Users Mailing List" <struts-user@jakarta.apache.org>
>>>>>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
>>>>>>>delegate....although 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" <rtaylor@mulework.com>
>>>>>>>To: "Struts Users Mailing List" <struts-user@jakarta.apache.org>
>>>>>>>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 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:ahardy.struts@cyberspaceroad.com]
>>>>>>>>>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: struts-user-unsubscribe@jakarta.apache.org
>>>>>>>>>For additional commands, e-mail: struts-user-help@jakarta.apache.org
>>>>>>>>>
>>>>>>>>
>>>>>>>>---------------------------------------------------------------------
>>>>>>>>To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
>>>>>>>>For additional commands, e-mail: struts-user-help@jakarta.apache.org
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>---------------------------------------------------------------------
>>>>>>>To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
>>>>>>>For additional commands, e-mail: struts-user-help@jakarta.apache.org
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>>-- 
>>>>>>struts 1.1 + tomcat 5.0.16 + java 1.4.2
>>>>>>Linux 2.4.20 Debian
>>>>>>
>>>>>>
>>>>>>---------------------------------------------------------------------
>>>>>>To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
>>>>>>For additional commands, e-mail: struts-user-help@jakarta.apache.org
>>>>>>
>>>>>
>>>>>
>>>>>---------------------------------------------------------------------
>>>>>To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
>>>>>For additional commands, e-mail: struts-user-help@jakarta.apache.org
>>>>>
>>>>
>>>>
>>>>
>>>>---------------------------------------------------------------------
>>>>To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
>>>>For additional commands, e-mail: struts-user-help@jakarta.apache.org
>>>>
>>>>
>>>
>>>
>>>-- 
>>>struts 1.1 + tomcat 5.0.16 + java 1.4.2
>>>Linux 2.4.20 Debian
>>>
>>>
>>>---------------------------------------------------------------------
>>>To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
>>>For additional commands, e-mail: struts-user-help@jakarta.apache.org
>>>
>>
>>
>>---------------------------------------------------------------------
>>To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
>>For additional commands, e-mail: struts-user-help@jakarta.apache.org
> 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: struts-user-help@jakarta.apache.org
> 
> 


-- 
struts 1.1 + tomcat 5.0.16 + java 1.4.2
Linux 2.4.20 Debian


---------------------------------------------------------------------
To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-user-help@jakarta.apache.org


Mime
View raw message