You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@struts.apache.org by Tim Christopher <ti...@gmail.com> on 2005/02/26 00:43:10 UTC

Struts Approach

Hi,

I'm currently designing a web application and as time progresses I
keep on less convinced that my approach is correct.

Applying what I have to a shop example the classes I have are:

------------------------------------------------------
* Note: I use the iBATIS framework.
------------------------------------------------------
Customer.java
# Contains get + set methods using correct types, ie. name (String),
age (int), etc.

CustomerDAO.java
# An interface for database operations for the Customer, i.e.
insertCustomer, updateCustomer, etc.

CustomerSqlMapDAO.java
# Implements the CustomerDAO interface and effectively calls the db.

CustomerService.java
# Used to gain access to CustomerDAO and CustomerSqlMapDAO.

CustomerDispatchAction.java (ex insert method - but will contain CRUD)
# Gets instance of CustomerService; copies jsp form details into a
DynaActionForm; copy form DynaActionForm to Customer.java object;
calls insert method in CustomerService with Customer object as the
parameter; return ActionForward.

Struts-Config.xml
# Contains DynaValidatorForm for storing customer details.
------------------------------------------------------
------------------------------------------------------

I've tried looking through a few books and using Google for
information that would explain if this is the correct approach, but
all the tutorials I can find only show examples of projects that are
very small.

I'm now at the stage in my project where I think I still have time to
change the design if I do it in the next couple of days - otherwise
I'm stuck with the approach I'm using above.

I think the closest I've come to finding anything is here:
http://java.sun.com/blueprints/corej2eepatterns/Patterns/

...  Though to be honest I don't really understand it.  

Can someone take a look at my previous example and suggest any extra
classes I should be using.  Also it would be useful if you could let
me know how the existing files link up to being: DAOs, DTOs, Value
Objects (same of DTO?!), and business classes.

I think I'm a little confused! :os

Any help would be appreciated.

Tim Christopher

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

Re: [OT] Struts Approach

Posted by NetSQL <ma...@friendVU.com>.
I call them API ex:

http://www.sandrasf.com/other/sandra/javadoc/index.html?org/sandra/api/package-summary.html

and Impl.

.V


Larry Meadors wrote:

> At any rate, it boils down to personal preference. As the tech lead
> where I work, I would publicly flog anyone who committed a
> ICustomerDao class to my CVS repository. ;-)
> 
> Larry


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

Re: [OT] Struts Approach

Posted by Leon Rosenberg <st...@anotheria.net>.
> But that is irrelevant, it is NOT necessary to distinguish 
> from similarly named classes because of the package structure 
> and/or class naming.


6.2.1 Naming Interfaces
The Java convention is to name interfaces using mixed case with the first
letter of each word capitalized. The
preferred Java convention for the name of an interface is to use a
descriptive adjective, such as Runnable or
Cloneable, although descriptive nouns, such as Singleton or DataInput, are
also common (Gosling, Joy,
Steele, 1996).
Alternatives:
1. Prefix the letter 'I' to the interface name. Coad and Mayfield (1997)
suggest appending the letter 'I' to
the front of an interface names, resulting in names like ISingleton or
IRunnable. This approach helps to
distinguish interface names from class and package names. I like this
potential naming convention for
the simple fact that it makes your class diagrams, sometimes referred to as
object models, easier to read.
The main disadvantage is that the existing interfaces, such as Runnable,
aren't named using this
approach, and I do not see them ever changing. Therefore I chose the defacto
standard described
above. This interface naming convention is also popular for Microsoft's
COM/DCOM architecture.
2. Postfix 'Ifc' onto the interface name. Lea (1996) suggests appending
'Ifc' to the end of an interface
name, resulting in names like SingletonIfc or RunnableIfc, whenever the name
of an interface is similar
to that of a class (Lea, 1996). I like the general idea, although I would be
tempted to prefix the name with
the full word 'Interface.' This suggestion suffers from the same problem as
the one above.

http://www.ambysoft.com/javaCodingStandards.pdf, P.46

Now, I remember, it was from "Building Object Applications That Work" by
Scott W. Ambler.


> 
> At any rate, it boils down to personal preference. 

True :-) And much better then: "Couldn't disagree more. ;-)" and "Nonsense.
Leave that for C coders. :-D" :-)


> As the tech lead where I work, I would publicly flog anyone who 
> committed a ICustomerDao class to my CVS repository. ;-)

It's your right and duty to decide on conventions :-)

Regards
Leon





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

Re: [OT] Struts Approach

Posted by Larry Meadors <la...@gmail.com>.
On Sat, 26 Feb 2005 15:30:12 +0100, <st...@anotheria.net> wrote:
> I just googled a bit :-)
> 
> Interface. When necessary to distinguish from similarly named classes:
> InterfaceNameEndsWithIfc.
> Class. When necessary to distinguish from similarly named interfaces:
> ClassNameEndsWithImpl OR
> ClassNameEndsWithObject
> 
> From
> http://gee.cs.oswego.edu/dl/html/javaCodingStd.html
> By Doug Lea

But that is irrelevant, it is NOT necessary to distinguish from
similarly named classes because of the package structure and/or class
naming.

At any rate, it boils down to personal preference. As the tech lead
where I work, I would publicly flog anyone who committed a
ICustomerDao class to my CVS repository. ;-)

Larry

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

Re: [OT] Re: Struts Approach

Posted by Andrew Hill <an...@gridnode.com>.
<snip>
 > Not to hit below the belt, but the only place that I have seen that
 > naming used in practice is in the Win32/COM world. Can you name
 > another? ;-)
</snip>

We do it as part of our coding conventions (we also do the Abstractxxx 
thing too). Im rather pro doing it that way too. Mostly its a matter of 
taste, though I do find it helps to visualise the design better (a 
diagram would also help - but who has time for that, and anyhow I think 
better in code than in pictures) - as soon as I see an Ixxx I know that 
its intended that will be different impls that plug in, and that Id get 
a lot further trying to instantiate one of those than the interface 
class... etc...
It works niely for us, but I doubt we would lose much doing it the other 
way. Certainly beats trying to think of new words that end in 'able'. 
;-) Ymmv...



Larry Meadors wrote:
> On Sat, 26 Feb 2005 14:30:18 +0100, <st...@anotheria.net> wrote:
> 
>>Can you tell me the exact difference between a leading "I" and a leading
>>"Abstract"  ?
>>
>>AbstractButton, AbstractModel, AbstractAction...
>>
> 
> 
> "Abstract" describes the behavior (the class is an abstract or partial
> implementation), where "I" is just a name mangler...I suppose you
> *could* argue that it describes the *lack of* behavior, but that still
> seems like nonsense. ;-)
> 
> 
>>>I am unaware of any interfaces in the JDK that are ISomething.
>>
>>There was almost none of those in jdks 1.0, 1.1.x and so on, till swing / 1.2.
>>Wait till 1.6 :-)
> 
> 
> OK, you made me look at 1.6, which I suppose is a good thing. :-) 
> 
> But you also proved my point - I am looking at it now, and see many,
> many interfaces, and not a *single one* that is named with a leading
> "I" that is not part of what the interface describes - and no,
> Iterator does not count...but it was still darn funny!
> 
> Not to hit below the belt, but the only place that I have seen that
> naming used in practice is in the Win32/COM world. Can you name
> another? ;-)
> 
> Larry
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
> For additional commands, e-mail: user-help@struts.apache.org
> 
> 


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

Re: [OT] Struts Approach

Posted by Leon Rosenberg <st...@anotheria.net>.
Hmm,

> "Abstract" describes the behavior (the class is an abstract 
> or partial implementation), where "I" is just a name 
> mangler...I suppose you
> *could* argue that it describes the *lack of* behavior, but 
> that still seems like nonsense. ;-)

I just googled a bit :-) 

Interface. When necessary to distinguish from similarly named classes: 
InterfaceNameEndsWithIfc. 
Class. When necessary to distinguish from similarly named interfaces: 
ClassNameEndsWithImpl OR 
ClassNameEndsWithObject 

>From 
http://gee.cs.oswego.edu/dl/html/javaCodingStd.html
By Doug Lea


I actually remember starting with CustomerServiceIFC-like named classes
about 1999, as we wrote our first middleware implementation (a CORBA clone),
and someone told me, that I- is the better way to do it. My team adopted
that and
I used it since then, with maybe about 50-100 develops, who actually
participated in
different teams and projects, and noone ever told me, it wouldn't be right
:-)

You are the first person, who ever questioned it. Still, I explicitely
welcome
anything, that makes the code more readable, and I- in front of an Interface
does the job.

If I'm making Code Review for a component, I first look for the I-Files,
where the 
components are described, then for "Base-" or "Abstract-" classes, and last,
for the
Detailclasses. 


Regards
Leon




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

Re: [OT] Re: Struts Approach

Posted by Larry Meadors <la...@gmail.com>.
On Sat, 26 Feb 2005 14:30:18 +0100, <st...@anotheria.net> wrote:
> Can you tell me the exact difference between a leading "I" and a leading
> "Abstract"  ?
>
> AbstractButton, AbstractModel, AbstractAction...
> 

"Abstract" describes the behavior (the class is an abstract or partial
implementation), where "I" is just a name mangler...I suppose you
*could* argue that it describes the *lack of* behavior, but that still
seems like nonsense. ;-)

> > I am unaware of any interfaces in the JDK that are ISomething.
> There was almost none of those in jdks 1.0, 1.1.x and so on, till swing / 1.2.
> Wait till 1.6 :-)

OK, you made me look at 1.6, which I suppose is a good thing. :-) 

But you also proved my point - I am looking at it now, and see many,
many interfaces, and not a *single one* that is named with a leading
"I" that is not part of what the interface describes - and no,
Iterator does not count...but it was still darn funny!

Not to hit below the belt, but the only place that I have seen that
naming used in practice is in the Win32/COM world. Can you name
another? ;-)

Larry

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

Re: Struts Approach

Posted by Larry Meadors <la...@gmail.com>.
HAHAHAH


On Sat, 26 Feb 2005 14:32:22 +0100, Leon Rosenberg
<st...@anotheria.net> wrote:
> > I am unaware of any interfaces in the JDK that are ISomething.
> 
> I-terator?
> 
> :-))))))))
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
> For additional commands, e-mail: user-help@struts.apache.org
> 
>

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

Re: Struts Approach

Posted by Leon Rosenberg <st...@anotheria.net>.
> Personally, I find the "leading I on an interface" rule to 
> hurt readability, but worse is that it also tempts you to an 
> insidious practice of naming an interface with the I, and 
> then an implementation class the same way without the I.  
> Consider the two names:
> 
> * IThisIsAVeryLongName (interface describing part of your app's API)
> 
> * ThisIsAVeryLongName (class that implements IThisIsAVeryLongName)
> 
> Without studying closely, can you instantly tell the 
> difference?  I contend that it's easier to do that (although 
> not necessarily trivial with long names) with patterns like:
> 
> * ThisIsAVeryLongName (interface describing part of your app's API)
> 
> * ThisIsAVeryLongNameImpl (class that implements ThisIsAVeryLongName)
> 

Actually the I-Fraction I belong to says:
IThisIsAVeryLongName 
and 
ThisIsAVeryLongNameImpl 

as well as 

Aspect1ThisIsAVeryLongNameImpl and 
AnotherAspectThisIsAVeryLongNameImpl (like FileSystemThisIsAVeryLongNameImpl
and PostgresThisIsAVeryLongNameImpl)

along with 

ThisIsAVeryLongNameFactory

or, if you have more then one:
IThisIsAVeryLongNameFactory...



The clue is:

ThisIsAVeryLongName < is never used directly. 

Regards
Leon



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

Re: AW: AW: Struts Approach

Posted by Craig McClanahan <cr...@gmail.com>.
On Sat, 26 Feb 2005 06:24:06 -0700, Larry Meadors
<la...@gmail.com> wrote:
> On Sat, 26 Feb 2005 14:13:59 +0100, <st...@anotheria.net> wrote:
> > Hmm, i thought it's more or less standart for interfaces in the advanced
> > java community...
> >
> 
> Baloney.
> 
> HttpServletRequest? HttpServletResponse? ResultSet? List?
> 
> No leading "I" on any of those.
> 
> I am unaware of any interfaces in the JDK that are ISomething.
> 

Although the JDK and standard Java APIs do not use this convention,
there are indeed Java coders who do -- and, outside the Java world,
you'll certainly see this in ASP.NET APIs, for example.

Personally, I find the "leading I on an interface" rule to hurt
readability, but worse is that it also tempts you to an insidious
practice of naming an interface with the I, and then an implementation
class the same way without the I.  Consider the two names:

* IThisIsAVeryLongName (interface describing part of your app's API)

* ThisIsAVeryLongName (class that implements IThisIsAVeryLongName)

Without studying closely, can you instantly tell the difference?  I
contend that it's easier to do that (although not necessarily trivial
with long names) with patterns like:

* ThisIsAVeryLongName (interface describing part of your app's API)

* ThisIsAVeryLongNameImpl (class that implements ThisIsAVeryLongName)

Finally, in my own coding, I also find that I sometimes prefer
abstract classes rather than interfaces to model application APIs,
particularly where I intend to add new capabilities later (and where
adding a method to an interface breaks existing implementations, but
you can add a method to the abstract class that provides backwards
compatible default behavior).  I'd hate to have to rename the
interface or abstract class when I changed this decision, even if I'm
using an IDE that will do all the grunt work for me.

> Larry

Craig

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

Re: Struts Approach

Posted by Leon Rosenberg <st...@anotheria.net>.
> I am unaware of any interfaces in the JDK that are ISomething. 

I-terator? 

:-))))))))



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

[OT] Re: Struts Approach

Posted by Leon Rosenberg <st...@anotheria.net>.
Can you tell me the exact difference between a leading "I" and a leading
"Abstract"  ?

AbstractButton, AbstractModel, AbstractAction... 


> I am unaware of any interfaces in the JDK that are ISomething. 
There was almost none of those in jdks 1.0, 1.1.x and so on, till swing /
1.2.
Wait till 1.6 :-) 


Leon


> -----Ursprüngliche Nachricht-----
> Von: Larry Meadors [mailto:larry.meadors@gmail.com] 
> Gesendet: Samstag, 26. Februar 2005 14:24
> An: Struts Users Mailing List
> Betreff: Re: AW: AW: Struts Approach
> 
> On Sat, 26 Feb 2005 14:13:59 +0100, <st...@anotheria.net> wrote:
> > Hmm, i thought it's more or less standart for interfaces in the 
> > advanced java community...
> > 
> 
> Baloney.
> 
> HttpServletRequest? HttpServletResponse? ResultSet? List?
> 
> No leading "I" on any of those. 
> 
> I am unaware of any interfaces in the JDK that are ISomething. 
> 
> Larry
> 
> 
> > But you can of course drop any points to the kind of the class like 
> > "Service" "Factory" "DAO", "Action", "Bean" and the poor 
> "Abstract" and "I"
> > .... this will sure make it more readable...
> > 
> > And it's not hungarian since "Interface" is not a type.
> > 
> > Regards
> > Leon
> > 
> > > -----Ursprüngliche Nachricht-----
> > > Von: Larry Meadors [mailto:larry.meadors@gmail.com]
> > > Gesendet: Samstag, 26. Februar 2005 14:06
> > > An: Struts Users Mailing List
> > > Betreff: Re: AW: Struts Approach
> > >
> > > Couldn't disagree more. ;-)
> > >
> > > IMO, adding hungarian notation like that to a Java project is 
> > > pointless. What's next? sCustomerName? iCusomerId?
> > >
> > > Nonsense. Leave that for C coders. :-D
> > >
> > > Larry
> > >
> > >
> > > On Sat, 26 Feb 2005 13:58:41 +0100, Leon Rosenberg 
> > > <st...@anotheria.net> wrote:
> > > >
> > > > <leon>
> > > >   <2cents>
> > > > The interface should start with an 'I' -> ICustomerService, and 
> > > > you also need a CustomerServiceFactory to 
> create/retrieve/manager 
> > > > CustomerServiceImpl instances :-)
> > > >
> > > >   </2cents>
> > > > </leon>
> > >
> > > 
> --------------------------------------------------------------------
> > > - To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
> > > For additional commands, e-mail: user-help@struts.apache.org
> > >
> > >
> > 
> > 
> ---------------------------------------------------------------------
> > To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
> > For additional commands, e-mail: user-help@struts.apache.org
> > 
> >
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
> For additional commands, e-mail: user-help@struts.apache.org
> 
> 



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

Re: AW: AW: Struts Approach

Posted by Larry Meadors <la...@gmail.com>.
On Sat, 26 Feb 2005 14:13:59 +0100, <st...@anotheria.net> wrote:
> Hmm, i thought it's more or less standart for interfaces in the advanced
> java community...
> 

Baloney.

HttpServletRequest? HttpServletResponse? ResultSet? List?

No leading "I" on any of those. 

I am unaware of any interfaces in the JDK that are ISomething. 

Larry


> But you can of course drop any points to the kind of the class like
> "Service" "Factory" "DAO", "Action", "Bean" and the poor "Abstract" and "I"
> .... this will sure make it more readable...
> 
> And it's not hungarian since "Interface" is not a type.
> 
> Regards
> Leon
> 
> > -----Ursprüngliche Nachricht-----
> > Von: Larry Meadors [mailto:larry.meadors@gmail.com]
> > Gesendet: Samstag, 26. Februar 2005 14:06
> > An: Struts Users Mailing List
> > Betreff: Re: AW: Struts Approach
> >
> > Couldn't disagree more. ;-)
> >
> > IMO, adding hungarian notation like that to a Java project is
> > pointless. What's next? sCustomerName? iCusomerId?
> >
> > Nonsense. Leave that for C coders. :-D
> >
> > Larry
> >
> >
> > On Sat, 26 Feb 2005 13:58:41 +0100, Leon Rosenberg
> > <st...@anotheria.net> wrote:
> > >
> > > <leon>
> > >   <2cents>
> > > The interface should start with an 'I' -> ICustomerService, and you
> > > also need a CustomerServiceFactory to create/retrieve/manager
> > > CustomerServiceImpl instances :-)
> > >
> > >   </2cents>
> > > </leon>
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
> > For additional commands, e-mail: user-help@struts.apache.org
> >
> >
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
> For additional commands, e-mail: user-help@struts.apache.org
> 
>

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

Re: AW: Struts Approach

Posted by Dakota Jack <da...@gmail.com>.
DTOs are meant for efficient Internet transfers of data in a J2EE
environment.  If you don't have the problem that DTOs were meant to
solve, then you should not be using them.

Jack


On Mon, 28 Feb 2005 15:22:28 +0000, Tim Christopher
<ti...@gmail.com> wrote:
> So what you're saying is that if I include a separate DTO it doesn't
> really achieve anything extra - whilst at the same time creating more
> code to maintain and reducing performance?
> 
> Do you know if there is a formal writeup of what is in the blog,
> something article in a book / report or on a different web site -
> Google wasn't much help :-(
> 
> Tim Christopher
> 
> On Sun, 27 Feb 2005 16:26:35 -0500, Mike Millson
> <mm...@meritonlinesystems.com> wrote:
> > On Sat, 2005-02-26 at 11:26, Tim Christopher wrote:
> > >
> > > I'm also a little concerned that my domain object (Customer.java) is
> > > also my DTO - is this good practice?
> >
> > Take a look at the following article:
> > http://www.javaperformancetuning.com/news/roundup050.shtml
> >
> > I think the author makes a good point. Having a separate DTO class is
> > like domain persistence, a very odd concept to me. I agree w/ the
> > author. Pass the domain object as the DTO, not a separate DTO class.
> >
> > Mike
> >
> >
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
> For additional commands, e-mail: user-help@struts.apache.org
> 
> 


-- 
"You can lead a horse to water but you cannot make it float on its back."
~Dakota Jack~

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

Re: AW: Struts Approach

Posted by Mike Millson <mm...@meritonlinesystems.com>.
On Mon, 2005-02-28 at 12:27, Shey Rab Pawo wrote:
> <SNIP>
> On Mon, 28 Feb 2005 11:40:13 -0500, Mike Millson
> <mm...@meritonlinesystems.com> wrote:
> > On Mon, 2005-02-28 at 10:22, Tim Christopher wrote:
> > > So what you're saying is that if I include a separate DTO it doesn't
> > > really achieve anything extra - whilst at the same time creating more
> > > code to maintain and reducing performance?
> > 
> > Yes, that's what I think.
> </SNIP>
> 
> If you are in a J2EE environment and are looking at multiple remote
> calls, DTO/VOs make a lot of sense.  Please note that DTO/VOs can be
> used in composite objects which are really helpful in J2EE
> environments.  You may not have that sort of environment.
> 
> If you don't, then the usefulness of DTO/VO depends.  

That's a good point. I was definitely not thinking of a J2EE
environment, but a POJO environment.

Mike


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

Re: AW: Struts Approach

Posted by Shey Rab Pawo <pa...@gmail.com>.
<SNIP>
On Mon, 28 Feb 2005 11:40:13 -0500, Mike Millson
<mm...@meritonlinesystems.com> wrote:
> On Mon, 2005-02-28 at 10:22, Tim Christopher wrote:
> > So what you're saying is that if I include a separate DTO it doesn't
> > really achieve anything extra - whilst at the same time creating more
> > code to maintain and reducing performance?
> 
> Yes, that's what I think.
</SNIP>

If you are in a J2EE environment and are looking at multiple remote
calls, DTO/VOs make a lot of sense.  Please note that DTO/VOs can be
used in composite objects which are really helpful in J2EE
environments.  You may not have that sort of environment.

If you don't, then the usefulness of DTO/VO depends.  

Jack




-- 
No one ever went blind looking at the bright side of life.

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

Re: AW: Struts Approach

Posted by Mike Millson <mm...@meritonlinesystems.com>.
On Mon, 2005-02-28 at 10:22, Tim Christopher wrote:
> So what you're saying is that if I include a separate DTO it doesn't
> really achieve anything extra - whilst at the same time creating more
> code to maintain and reducing performance?

Yes, that's what I think.

> 
> Do you know if there is a formal writeup of what is in the blog,
> something article in a book / report or on a different web site -
> Google wasn't much help :-(

I have not seen a formal writeup.


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

Re: AW: Struts Approach

Posted by Dakota Jack <da...@gmail.com>.
Here is the general notes on when a DTO is needed:

Every method call made to the business service object, be it an entity
bean or a session bean, is potentially remote. Thus, in an Enterprise
JavaBeans (EJB) application such remote invocations use the network
layer regardless of the proximity of the client to the bean, creating
a network overhead. Enterprise bean method calls may permeate the
network layers of the system even if the client and the EJB container
holding the entity bean are both running in the same JVM, OS, or
physical machine. Some vendors may implement mechanisms to reduce this
overhead by using a more direct access approach and bypassing the
network.

As the usage of these remote methods increases, application
performance can significantly degrade. Therefore, using multiple calls
to get methods that return single attribute values is inefficient for
obtaining data values from an enterprise bean.
Forces

    *

      All access to an enterprise bean is performed via remote
interfaces to the bean. Every call to an enterprise bean is
potentially a remote method call with network overhead.
    * Typically, applications have a greater frequency of read
transactions than update transactions. The client requires the data
from the business tier for presentation, display, and other read-only
types of processing. The client updates the data in the business tier
much less frequently than it reads the data.
    * The client usually requires values for more than one attribute
or dependent object from an enterprise bean. Thus, the client may
invoke multiple remote calls to obtain the required data.
    * The number of calls made by the client to the enterprise bean
impacts network performance. Chattier applications-those with
increased traffic between client and server tiers-often degrade
network performance.

Solution

Use a Transfer Object to encapsulate the business data. A single
method call is used to send and retrieve the Transfer Object. When the
client requests the enterprise bean for the business data, the
enterprise bean can construct the Transfer Object, populate it with
its attribute values, and pass it by value to the client.

Clients usually require more than one value from an enterprise bean.
To reduce the number of remote calls and to avoid the associated
overhead, it is best to use this pattern.


On Mon, 28 Feb 2005 15:22:28 +0000, Tim Christopher
<ti...@gmail.com> wrote:
> So what you're saying is that if I include a separate DTO it doesn't
> really achieve anything extra - whilst at the same time creating more
> code to maintain and reducing performance?
> 
> Do you know if there is a formal writeup of what is in the blog,
> something article in a book / report or on a different web site -
> Google wasn't much help :-(
> 
> Tim Christopher
> 
> On Sun, 27 Feb 2005 16:26:35 -0500, Mike Millson
> <mm...@meritonlinesystems.com> wrote:
> > On Sat, 2005-02-26 at 11:26, Tim Christopher wrote:
> > >
> > > I'm also a little concerned that my domain object (Customer.java) is
> > > also my DTO - is this good practice?
> >
> > Take a look at the following article:
> > http://www.javaperformancetuning.com/news/roundup050.shtml
> >
> > I think the author makes a good point. Having a separate DTO class is
> > like domain persistence, a very odd concept to me. I agree w/ the
> > author. Pass the domain object as the DTO, not a separate DTO class.
> >
> > Mike
> >
> >
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
> For additional commands, e-mail: user-help@struts.apache.org
> 
> 


-- 
"You can lead a horse to water but you cannot make it float on its back."
~Dakota Jack~

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

Re: AW: Struts Approach

Posted by Larry Meadors <la...@gmail.com>.
I would agree with that point. 

Generally, my service classes take care of the domain logic, so the
DTO is as good a DO as I need.

Larry

On Mon, 28 Feb 2005 15:22:28 +0000, Tim Christopher
<ti...@gmail.com> wrote:
> So what you're saying is that if I include a separate DTO it doesn't
> really achieve anything extra - whilst at the same time creating more
> code to maintain and reducing performance?

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

Re: AW: Struts Approach

Posted by Tim Christopher <ti...@gmail.com>.
So what you're saying is that if I include a separate DTO it doesn't
really achieve anything extra - whilst at the same time creating more
code to maintain and reducing performance?

Do you know if there is a formal writeup of what is in the blog,
something article in a book / report or on a different web site -
Google wasn't much help :-(

Tim Christopher

On Sun, 27 Feb 2005 16:26:35 -0500, Mike Millson
<mm...@meritonlinesystems.com> wrote:
> On Sat, 2005-02-26 at 11:26, Tim Christopher wrote:
> >
> > I'm also a little concerned that my domain object (Customer.java) is
> > also my DTO - is this good practice?
> 
> Take a look at the following article:
> http://www.javaperformancetuning.com/news/roundup050.shtml
> 
> I think the author makes a good point. Having a separate DTO class is
> like domain persistence, a very odd concept to me. I agree w/ the
> author. Pass the domain object as the DTO, not a separate DTO class.
> 
> Mike
> 
>

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

Re: AW: Struts Approach

Posted by Mike Millson <mm...@meritonlinesystems.com>.
On Sat, 2005-02-26 at 11:26, Tim Christopher wrote:
> 
> I'm also a little concerned that my domain object (Customer.java) is
> also my DTO - is this good practice?

Take a look at the following article:
http://www.javaperformancetuning.com/news/roundup050.shtml

I think the author makes a good point. Having a separate DTO class is
like domain persistence, a very odd concept to me. I agree w/ the
author. Pass the domain object as the DTO, not a separate DTO class.

Mike


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

Re: AW: Struts Approach

Posted by Tim Christopher <ti...@gmail.com>.
> I put a nested Customer object in my action form, and deal with type
> conversions from the web layer there (i.e., dates, numbers, etc) so
> that by the time my action gets involved, it can get the customer from
> the form and pass it to the service layer without worrying too much
> about that stuff. 

Following feedback the code within my Action is roughly the equivilent
of the code below:

CustomerServiceImp customerService = CustomerServiceImp.getInstance();
customerForm customerForm = (CustomerForm) form;
Customer customer = new Customer();
BeanUtils.copyProperties(customer, customerForm);
customerService.insertCustomer(customer);

As far as I'm aware the copyProperties method in BeanUtils deals with
all conversions between the variables (all String) in the
customerForm, and the correctly typed variables within Customer (int,
double, String, date etc - though at the moment it only contains int's
and String's).

I'd like to be able to copy each property off the form indivudally and
do the conversion myself, which I think is what you're doing (quoted
text) - but I'm not sure how to go about doing this. :-(

I'm also a little concerned that my domain object (Customer.java) is
also my DTO - is this good practice?

Thanks for all your help so far,

Tim Christopher

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

AW: AW: Struts Approach

Posted by Leon Rosenberg <st...@anotheria.net>.
Hmm, i thought it's more or less standart for interfaces in the advanced
java community...
 
But you can of course drop any points to the kind of the class like
"Service" "Factory" "DAO", "Action", "Bean" and the poor "Abstract" and "I"
.... this will sure make it more readable...

And it's not hungarian since "Interface" is not a type. 

Regards
Leon

> -----Ursprüngliche Nachricht-----
> Von: Larry Meadors [mailto:larry.meadors@gmail.com] 
> Gesendet: Samstag, 26. Februar 2005 14:06
> An: Struts Users Mailing List
> Betreff: Re: AW: Struts Approach
> 
> Couldn't disagree more. ;-)
> 
> IMO, adding hungarian notation like that to a Java project is 
> pointless. What's next? sCustomerName? iCusomerId?
> 
> Nonsense. Leave that for C coders. :-D
> 
> Larry
> 
> 
> On Sat, 26 Feb 2005 13:58:41 +0100, Leon Rosenberg 
> <st...@anotheria.net> wrote:
> > 
> > <leon>
> >   <2cents>
> > The interface should start with an 'I' -> ICustomerService, and you 
> > also need a CustomerServiceFactory to create/retrieve/manager 
> > CustomerServiceImpl instances :-)
> > 
> >   </2cents>
> > </leon>
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
> For additional commands, e-mail: user-help@struts.apache.org
> 
> 



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

Re: AW: Struts Approach

Posted by Larry Meadors <la...@gmail.com>.
Couldn't disagree more. ;-)

IMO, adding hungarian notation like that to a Java project is
pointless. What's next? sCustomerName? iCusomerId?

Nonsense. Leave that for C coders. :-D

Larry


On Sat, 26 Feb 2005 13:58:41 +0100, Leon Rosenberg
<st...@anotheria.net> wrote:
> 
> <leon>
>   <2cents>
> The interface should start with an 'I' -> ICustomerService, and you
> also need a CustomerServiceFactory to create/retrieve/manager
> CustomerServiceImpl
> instances :-)
> 
>   </2cents>
> </leon>

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

AW: Struts Approach

Posted by Leon Rosenberg <st...@anotheria.net>.
<leon>
  <2cents>

> for the application CustomerService.java - the interface for 
> the service layer CustomerServiceImpl.java - the 

The interface should start with an 'I' -> ICustomerService, and you
also need a CustomerServiceFactory to create/retrieve/manager
CustomerServiceImpl
instances :-)

  </2cents>
</leon>



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

Re: Struts Approach

Posted by Larry Meadors <la...@gmail.com>.
Tim,

What you are describing is actually very close to how I build struts
apps with iBATIS.

Starting with your example of a Customer maintenance application, here
are the components I would create:

Customer.java - a typed bean that describes the properties of a customer
CustomerDao.java - the interface for the DAO layer
CustomerDaoImpl.java - the implementation of the interface for the DAO layer
CustomerAction.java - a dispatch action for the application
CustomerForm.java - a regular (non-dyna) form for the application
CustomerService.java - the interface for the service layer
CustomerServiceImpl.java - the implementation of the interface for the
service layer

There are two parts here that can be controversial: The non-dyna
CustomerForm, and the seperation of the service interface and
implementation.

I do both for the sake of testing - I try to get 100% coverage with my
unit tests, so explicit behavior (like with the non-dyna CustomerForm)
and loose coupling (with the added service interface) are quite
helpful.

I put a nested Customer object in my action form, and deal with type
conversions from the web layer there (i.e., dates, numbers, etc) so
that by the time my action gets involved, it can get the customer from
the form and pass it to the service layer without worrying too much
about that stuff. For types that bean-utils does well with, I simply
delegate to the Customer bean from the action form (public String
getName(){return getCustomer().getName;}). Yes, it is some extra code
that you would avoid with a dyna, but I prefer the explicit behavior,
because IMO, it is easier to test and debug when problems arise, and
you really do not eliminate much code with the dyna bean approach -
you simply move it into an XML file. ;-)

For testing, I use constructors to provide the service implementation
to the action class, and to provide the dao implementation to the
service class. When the application runs normally, it gets the
implementations from the factories (I use a service factory as well as
a dao factory).

HTH,
Larry


On Fri, 25 Feb 2005 23:43:10 +0000, Tim Christopher
<ti...@gmail.com> wrote:
> Hi,
> 
> I'm currently designing a web application and as time progresses I
> keep on less convinced that my approach is correct.
> 
> Applying what I have to a shop example the classes I have are:
> 
> ------------------------------------------------------
> * Note: I use the iBATIS framework.
> ------------------------------------------------------
> Customer.java
> # Contains get + set methods using correct types, ie. name (String),
> age (int), etc.
> 
> CustomerDAO.java
> # An interface for database operations for the Customer, i.e.
> insertCustomer, updateCustomer, etc.
> 
> CustomerSqlMapDAO.java
> # Implements the CustomerDAO interface and effectively calls the db.
> 
> CustomerService.java
> # Used to gain access to CustomerDAO and CustomerSqlMapDAO.
> 
> CustomerDispatchAction.java (ex insert method - but will contain CRUD)
> # Gets instance of CustomerService; copies jsp form details into a
> DynaActionForm; copy form DynaActionForm to Customer.java object;
> calls insert method in CustomerService with Customer object as the
> parameter; return ActionForward.
> 
> Struts-Config.xml
> # Contains DynaValidatorForm for storing customer details.
> ------------------------------------------------------
> ------------------------------------------------------
> 
> I've tried looking through a few books and using Google for
> information that would explain if this is the correct approach, but
> all the tutorials I can find only show examples of projects that are
> very small.
> 
> I'm now at the stage in my project where I think I still have time to
> change the design if I do it in the next couple of days - otherwise
> I'm stuck with the approach I'm using above.
> 
> I think the closest I've come to finding anything is here:
> http://java.sun.com/blueprints/corej2eepatterns/Patterns/
> 
> ...  Though to be honest I don't really understand it.
> 
> Can someone take a look at my previous example and suggest any extra
> classes I should be using.  Also it would be useful if you could let
> me know how the existing files link up to being: DAOs, DTOs, Value
> Objects (same of DTO?!), and business classes.
> 
> I think I'm a little confused! :os
> 
> Any help would be appreciated.
> 
> Tim Christopher
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
> For additional commands, e-mail: user-help@struts.apache.org
> 
>

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

Re: Struts Approach

Posted by Erik Weber <er...@mindspring.com>.
I think you're doing fine. What is your cause for concern? Does your 
application behave as you expect? As long as the business decisions are 
mostly made by your CustomerService object, you're on the right track.

DTO == value object.

As far as adding "extra classes", why? The goal is to *reduce* 
unnecessary code . . .

Erik



Tim Christopher wrote:

>Hi,
>
>I'm currently designing a web application and as time progresses I
>keep on less convinced that my approach is correct.
>
>Applying what I have to a shop example the classes I have are:
>
>------------------------------------------------------
>* Note: I use the iBATIS framework.
>------------------------------------------------------
>Customer.java
># Contains get + set methods using correct types, ie. name (String),
>age (int), etc.
>
>CustomerDAO.java
># An interface for database operations for the Customer, i.e.
>insertCustomer, updateCustomer, etc.
>
>CustomerSqlMapDAO.java
># Implements the CustomerDAO interface and effectively calls the db.
>
>CustomerService.java
># Used to gain access to CustomerDAO and CustomerSqlMapDAO.
>
>CustomerDispatchAction.java (ex insert method - but will contain CRUD)
># Gets instance of CustomerService; copies jsp form details into a
>DynaActionForm; copy form DynaActionForm to Customer.java object;
>calls insert method in CustomerService with Customer object as the
>parameter; return ActionForward.
>
>Struts-Config.xml
># Contains DynaValidatorForm for storing customer details.
>------------------------------------------------------
>------------------------------------------------------
>
>I've tried looking through a few books and using Google for
>information that would explain if this is the correct approach, but
>all the tutorials I can find only show examples of projects that are
>very small.
>
>I'm now at the stage in my project where I think I still have time to
>change the design if I do it in the next couple of days - otherwise
>I'm stuck with the approach I'm using above.
>
>I think the closest I've come to finding anything is here:
>http://java.sun.com/blueprints/corej2eepatterns/Patterns/
>
>...  Though to be honest I don't really understand it.  
>
>Can someone take a look at my previous example and suggest any extra
>classes I should be using.  Also it would be useful if you could let
>me know how the existing files link up to being: DAOs, DTOs, Value
>Objects (same of DTO?!), and business classes.
>
>I think I'm a little confused! :os
>
>Any help would be appreciated.
>
>Tim Christopher
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
>For additional commands, e-mail: user-help@struts.apache.org
>
>
>  
>

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

Re: Struts Approach

Posted by Vamsee Kanakala <va...@gmail.com>.
Tim Christopher wrote:

>CustomerService.java
># Used to gain access to CustomerDAO and CustomerSqlMapDAO.
>
>CustomerDispatchAction.java (ex insert method - but will contain CRUD)
># Gets instance of CustomerService; copies jsp form details into a
>DynaActionForm; copy form DynaActionForm to Customer.java object;
>calls insert method in CustomerService with Customer object as the
>parameter; return ActionForward.
>
>  
>
I'm interested in learning what the above classes do - can you please 
elaborate? Can you post/point to a little code? I'm particularly 
interested in how DispatchAction class can be used.

Thanks,
Vamsee.

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

Re: Struts Approach

Posted by Larry Meadors <la...@gmail.com>.
On Fri, 25 Feb 2005 16:27:09 -0800, <pa...@gmail.com> wrote:
> Without knowing more details it is hard to respond.  I did find the
> description of the relations between the DAO objects a bit "off" from
> what I would have expected.  I would have expected something like:
> 
> CustomerDAO customerDAO = FactoryDAO.getCustomerDAO();
> 
> This assumes that the CustomerDAO is an interface and that
> getCustomerDAO() in FactoryDAO is setup to get the default
> implementation of the CustomerDAO.  If CustomerSqlMapDAO is such an
> implementation, then I understand.  The naming is just a bit odd to
> me.  (I don't use iBatis and that may be standard terminology there.)
> 

I am assuming that Tim is using the iBATIS DAO layer as well as
SQLMaps, so what you are describing is pretty accurate.

The factory call is *slightly* different - in iBATIS, we use an
factory that requires you to cast the returned DAO:

CustomerDao dao = (CustomerDao)daoManager.getDao(CustomerDao.class);

Larry

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

Re: Struts Approach

Posted by Shey Rab Pawo <pa...@gmail.com>.
Without knowing more details it is hard to respond.  I did find the
description of the relations between the DAO objects a bit "off" from
what I would have expected.  I would have expected something like:

CustomerDAO customerDAO = FactoryDAO.getCustomerDAO();

This assumes that the CustomerDAO is an interface and that
getCustomerDAO() in FactoryDAO is setup to get the default
implementation of the CustomerDAO.  If CustomerSqlMapDAO is such an
implementation, then I understand.  The naming is just a bit odd to
me.  (I don't use iBatis and that may be standard terminology there.)

With that small question in the back of my mind, this looks good.  I
would use the methods in the dispatch action to pass the detail work
off to helper objects in the model.


On Fri, 25 Feb 2005 23:43:10 +0000, Tim Christopher
<ti...@gmail.com> wrote:
> Hi,
> 
> I'm currently designing a web application and as time progresses I
> keep on less convinced that my approach is correct.
> 
> Applying what I have to a shop example the classes I have are:
> 
> ------------------------------------------------------
> * Note: I use the iBATIS framework.
> ------------------------------------------------------
> Customer.java
> # Contains get + set methods using correct types, ie. name (String),
> age (int), etc.
> 
> CustomerDAO.java
> # An interface for database operations for the Customer, i.e.
> insertCustomer, updateCustomer, etc.
> 
> CustomerSqlMapDAO.java
> # Implements the CustomerDAO interface and effectively calls the db.
> 
> CustomerService.java
> # Used to gain access to CustomerDAO and CustomerSqlMapDAO.
> 
> CustomerDispatchAction.java (ex insert method - but will contain CRUD)
> # Gets instance of CustomerService; copies jsp form details into a
> DynaActionForm; copy form DynaActionForm to Customer.java object;
> calls insert method in CustomerService with Customer object as the
> parameter; return ActionForward.
> 
> Struts-Config.xml
> # Contains DynaValidatorForm for storing customer details.
> ------------------------------------------------------
> ------------------------------------------------------
> 
> I've tried looking through a few books and using Google for
> information that would explain if this is the correct approach, but
> all the tutorials I can find only show examples of projects that are
> very small.
> 
> I'm now at the stage in my project where I think I still have time to
> change the design if I do it in the next couple of days - otherwise
> I'm stuck with the approach I'm using above.
> 
> I think the closest I've come to finding anything is here:
> http://java.sun.com/blueprints/corej2eepatterns/Patterns/
> 
> ...  Though to be honest I don't really understand it.
> 
> Can someone take a look at my previous example and suggest any extra
> classes I should be using.  Also it would be useful if you could let
> me know how the existing files link up to being: DAOs, DTOs, Value
> Objects (same of DTO?!), and business classes.
> 
> I think I'm a little confused! :os
> 
> Any help would be appreciated.
> 
> Tim Christopher
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
> For additional commands, e-mail: user-help@struts.apache.org
> 
> 


-- 
No one ever went blind looking at the bright side of life.

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

Re: Struts Approach

Posted by Erik Weber <er...@mindspring.com>.
Thanks a lot.

Erik



Robert Taylor wrote:

> > So, this additional layer, in a Struts application, resides between the
> > Struts classes (Actions) and your managerial facade? The Action
> > instantiates/looks up a CustomerApplicationServiceImpl, which does CRUD
> > via the CustomerService component but also manages (possibly by itself,
> > possibly by delegation) app-specific notification logic, high-level 
> view
> > helper logic, etc. Is this correct?
> Yes. The application service becomes the core of the application 
> specific logic. As such, it is the most volatile. Once the domain 
> components (domain object, dao, and manager) are created to perform 
> operations which are relative to their respective domain, then they 
> shouldn't change much and essentially become a library of reusable 
> components. Contrary to an application service which are subject to 
> the whim of the business contraints.
>
>
>
> >Effectively then, this layer
> > decouples the managerial layer from, not Struts per se (though it does
> > indirectly), but, from your implementation strategy (whether you use
> > passive/active notification, how you filter read results, etc.) with
> > respect to the business rules. Right?
> Yes. As mentioned above. Just to clarify, I consider the managerial 
> layer to manage the domain component (domain object and its respective 
> dao). If the "implementation strategy" refers to the implementation of 
> the application specific logic, then yes.
>
>
> This strategy mainly falls out of my own experience with doing just 
> what I cautioned against. I started developing domain objects using an 
> ActiveRecord (see Martin Fowler) design pattern and then each time a 
> new application requirement was added, I ended up adding a static 
> method to my domain object. After a while my domain object was doing 
> things waaaaayyyy out of its domain and consequentially not as 
> reusable. I have found this to be a common pitfall in application 
> development; especially as the application goes from "simple" to 
> complex and critical.
>
>
> After some research (reading Core J2EE Patterns, Rod Johnson, etc...) 
> and lots of refactoring, I started using the strategy I just described 
> and have found the applications have been more scalable and most of 
> the changes tend to be isolated in the application service layer.
>
>
>
> /robert
>
>
>
> Erik Weber wrote:
>
>> Robert Taylor wrote:
>>
>>> Tim,
>>>
>>> I think things look pretty good so far.
>>>
>>> Right now Customer is a domain object representing a customer.
>>> CustomerDAO is a DAO respsonible for mapping the Customer to its 
>>> relational counterpart(s). CustomerService collaborates with 
>>> CustomerDAO  to manage the persistence and data access of a Customer.
>>> Together these 3 classes make up what I would refer to as a 
>>> CustomerComponent. This simple component can be used in any of your 
>>> applications that interact with a customer and need simple Customer 
>>> CRUD (create, retrieve, update, and delete) services.
>>>
>>> I would caution you against adding any application specific logic to 
>>> this component as it would reduce the reusability of it in other 
>>> applications which you may develop which may need to use the same 
>>> component. I'm assuming right now your application logic mirrors the 
>>> services provided by the CustomerService; simple CRUD  operations. 
>>> Now let's say you have some additional requirements such as:
>>>
>>> - When a customer is created, notify operations.
>>> - When a customer is deleted, notify operations.
>>> - Find all the customer's who have placed orders within a specified
>>>   date range.
>>>
>>> You might be tempted to add this functionality to CustomerService 
>>> and add the supporting functionality to CustomerDAO and Customer. 
>>> Now let's say you need to develop another application which needs 
>>> simple CRUD functionality for a Customer. Ooops. You can't use 
>>> CustomerService.
>>>
>>> I have found that an additional application service layer provides 
>>> the flexibility to add application specific logic leveraging a 
>>> library of components instead of modifying them. For example, you 
>>> might want to add a CustomerApplicationService which leverages the 
>>> services provided by CustomerService. So for the example provided 
>>> above, the CustomerApplicationService may collaborate with event 
>>> listeners which respond appropriately to creating and deleting a 
>>> customer. It may also collaborate with specialized DAO for 
>>> retrieveing customer's using application logic criteria. It may also 
>>> collaborate with value object assemblers to build value objects 
>>> which cannot simply be represented by a single Customer. My point is 
>>> that the additional layer provides a layer of abstraction which 
>>> decouples the domain components from application specific logic 
>>> which allows you to leverage your investments in these domain 
>>> components, instead of modifying them to support additional 
>>> application requirements.
>>
>>
>>
>>
>> So, this additional layer, in a Struts application, resides between 
>> the Struts classes (Actions) and your managerial facade? The Action 
>> instantiates/looks up a CustomerApplicationServiceImpl, which does 
>> CRUD via the CustomerService component but also manages (possibly by 
>> itself, possibly by delegation) app-specific notification logic, 
>> high-level view helper logic, etc. Is this correct? Effectively then, 
>> this layer decouples the managerial layer from, not Struts per se 
>> (though it does indirectly), but, from your implementation strategy 
>> (whether you use passive/active notification, how you filter read 
>> results, etc.) with respect to the business rules. Right?
>>
>> Thanks,
>> Erik
>>
>>
>>>
>>> Don't forget that CustomerApplicationService should be an interface 
>>> such  that it can be implemented as a POJO (plain old java object) 
>>> or maybe a delegate which hides a remote implementation.
>>>
>>>
>>>
>>> /robert
>>>
>>>
>>> Tim Christopher wrote:
>>>
>>>> Hi,
>>>>
>>>> I'm currently designing a web application and as time progresses I
>>>> keep on less convinced that my approach is correct.
>>>>
>>>> Applying what I have to a shop example the classes I have are:
>>>>
>>>> ------------------------------------------------------
>>>> * Note: I use the iBATIS framework.
>>>> ------------------------------------------------------
>>>> Customer.java
>>>> # Contains get + set methods using correct types, ie. name (String),
>>>> age (int), etc.
>>>>
>>>> CustomerDAO.java
>>>> # An interface for database operations for the Customer, i.e.
>>>> insertCustomer, updateCustomer, etc.
>>>>
>>>> CustomerSqlMapDAO.java
>>>> # Implements the CustomerDAO interface and effectively calls the db.
>>>>
>>>> CustomerService.java
>>>> # Used to gain access to CustomerDAO and CustomerSqlMapDAO.
>>>>
>>>> CustomerDispatchAction.java (ex insert method - but will contain CRUD)
>>>> # Gets instance of CustomerService; copies jsp form details into a
>>>> DynaActionForm; copy form DynaActionForm to Customer.java object;
>>>> calls insert method in CustomerService with Customer object as the
>>>> parameter; return ActionForward.
>>>>
>>>> Struts-Config.xml
>>>> # Contains DynaValidatorForm for storing customer details.
>>>> ------------------------------------------------------
>>>> ------------------------------------------------------
>>>>
>>>> I've tried looking through a few books and using Google for
>>>> information that would explain if this is the correct approach, but
>>>> all the tutorials I can find only show examples of projects that are
>>>> very small.
>>>>
>>>> I'm now at the stage in my project where I think I still have time to
>>>> change the design if I do it in the next couple of days - otherwise
>>>> I'm stuck with the approach I'm using above.
>>>>
>>>> I think the closest I've come to finding anything is here:
>>>> http://java.sun.com/blueprints/corej2eepatterns/Patterns/
>>>>
>>>> ...  Though to be honest I don't really understand it. Can someone 
>>>> take a look at my previous example and suggest any extra
>>>> classes I should be using.  Also it would be useful if you could let
>>>> me know how the existing files link up to being: DAOs, DTOs, Value
>>>> Objects (same of DTO?!), and business classes.
>>>>
>>>> I think I'm a little confused! :os
>>>>
>>>> Any help would be appreciated.
>>>>
>>>> Tim Christopher
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
>>>> For additional commands, e-mail: user-help@struts.apache.org
>>>>
>>>>
>>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
>>> For additional commands, e-mail: user-help@struts.apache.org
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
>> For additional commands, e-mail: user-help@struts.apache.org
>>
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
> For additional commands, e-mail: user-help@struts.apache.org
>
>

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

Re: Struts Approach

Posted by Robert Taylor <64...@bellsouth.net>.
 > So, this additional layer, in a Struts application, resides between the
 > Struts classes (Actions) and your managerial facade? The Action
 > instantiates/looks up a CustomerApplicationServiceImpl, which does CRUD
 > via the CustomerService component but also manages (possibly by itself,
 > possibly by delegation) app-specific notification logic, high-level view
 > helper logic, etc. Is this correct?
Yes. The application service becomes the core of the application 
specific logic. As such, it is the most volatile. Once the domain 
components (domain object, dao, and manager) are created to perform 
operations which are relative to their respective domain, then they 
shouldn't change much and essentially become a library of reusable 
components. Contrary to an application service which are subject to the 
whim of the business contraints.



 >Effectively then, this layer
 > decouples the managerial layer from, not Struts per se (though it does
 > indirectly), but, from your implementation strategy (whether you use
 > passive/active notification, how you filter read results, etc.) with
 > respect to the business rules. Right?
Yes. As mentioned above. Just to clarify, I consider the managerial 
layer to manage the domain component (domain object and its respective 
dao). If the "implementation strategy" refers to the implementation of 
the application specific logic, then yes.


This strategy mainly falls out of my own experience with doing just what 
I cautioned against. I started developing domain objects using an 
ActiveRecord (see Martin Fowler) design pattern and then each time a new 
application requirement was added, I ended up adding a static method to 
my domain object. After a while my domain object was doing things 
waaaaayyyy out of its domain and consequentially not as reusable. I have 
found this to be a common pitfall in application development; especially 
as the application goes from "simple" to complex and critical.


After some research (reading Core J2EE Patterns, Rod Johnson, etc...) 
and lots of refactoring, I started using the strategy I just described 
and have found the applications have been more scalable and most of the 
changes tend to be isolated in the application service layer.



/robert



Erik Weber wrote:
> Robert Taylor wrote:
> 
>> Tim,
>>
>> I think things look pretty good so far.
>>
>> Right now Customer is a domain object representing a customer.
>> CustomerDAO is a DAO respsonible for mapping the Customer to its 
>> relational counterpart(s). CustomerService collaborates with 
>> CustomerDAO  to manage the persistence and data access of a Customer.
>> Together these 3 classes make up what I would refer to as a 
>> CustomerComponent. This simple component can be used in any of your 
>> applications that interact with a customer and need simple Customer 
>> CRUD (create, retrieve, update, and delete) services.
>>
>> I would caution you against adding any application specific logic to 
>> this component as it would reduce the reusability of it in other 
>> applications which you may develop which may need to use the same 
>> component. I'm assuming right now your application logic mirrors the 
>> services provided by the CustomerService; simple CRUD  operations. Now 
>> let's say you have some additional requirements such as:
>>
>> - When a customer is created, notify operations.
>> - When a customer is deleted, notify operations.
>> - Find all the customer's who have placed orders within a specified
>>   date range.
>>
>> You might be tempted to add this functionality to CustomerService and 
>> add the supporting functionality to CustomerDAO and Customer. Now 
>> let's say you need to develop another application which needs simple 
>> CRUD functionality for a Customer. Ooops. You can't use CustomerService.
>>
>> I have found that an additional application service layer provides the 
>> flexibility to add application specific logic leveraging a library of 
>> components instead of modifying them. For example, you might want to 
>> add a CustomerApplicationService which leverages the services provided 
>> by CustomerService. So for the example provided above, the 
>> CustomerApplicationService may collaborate with event listeners which 
>> respond appropriately to creating and deleting a customer. It may also 
>> collaborate with specialized DAO for retrieveing customer's using 
>> application logic criteria. It may also collaborate with value object 
>> assemblers to build value objects which cannot simply be represented 
>> by a single Customer. My point is that the additional layer provides a 
>> layer of abstraction which decouples the domain components from 
>> application specific logic which allows you to leverage your 
>> investments in these domain components, instead of modifying them to 
>> support additional application requirements.
> 
> 
> 
> So, this additional layer, in a Struts application, resides between the 
> Struts classes (Actions) and your managerial facade? The Action 
> instantiates/looks up a CustomerApplicationServiceImpl, which does CRUD 
> via the CustomerService component but also manages (possibly by itself, 
> possibly by delegation) app-specific notification logic, high-level view 
> helper logic, etc. Is this correct? Effectively then, this layer 
> decouples the managerial layer from, not Struts per se (though it does 
> indirectly), but, from your implementation strategy (whether you use 
> passive/active notification, how you filter read results, etc.) with 
> respect to the business rules. Right?
> 
> Thanks,
> Erik
> 
> 
>>
>> Don't forget that CustomerApplicationService should be an interface 
>> such  that it can be implemented as a POJO (plain old java object) or 
>> maybe a delegate which hides a remote implementation.
>>
>>
>>
>> /robert
>>
>>
>> Tim Christopher wrote:
>>
>>> Hi,
>>>
>>> I'm currently designing a web application and as time progresses I
>>> keep on less convinced that my approach is correct.
>>>
>>> Applying what I have to a shop example the classes I have are:
>>>
>>> ------------------------------------------------------
>>> * Note: I use the iBATIS framework.
>>> ------------------------------------------------------
>>> Customer.java
>>> # Contains get + set methods using correct types, ie. name (String),
>>> age (int), etc.
>>>
>>> CustomerDAO.java
>>> # An interface for database operations for the Customer, i.e.
>>> insertCustomer, updateCustomer, etc.
>>>
>>> CustomerSqlMapDAO.java
>>> # Implements the CustomerDAO interface and effectively calls the db.
>>>
>>> CustomerService.java
>>> # Used to gain access to CustomerDAO and CustomerSqlMapDAO.
>>>
>>> CustomerDispatchAction.java (ex insert method - but will contain CRUD)
>>> # Gets instance of CustomerService; copies jsp form details into a
>>> DynaActionForm; copy form DynaActionForm to Customer.java object;
>>> calls insert method in CustomerService with Customer object as the
>>> parameter; return ActionForward.
>>>
>>> Struts-Config.xml
>>> # Contains DynaValidatorForm for storing customer details.
>>> ------------------------------------------------------
>>> ------------------------------------------------------
>>>
>>> I've tried looking through a few books and using Google for
>>> information that would explain if this is the correct approach, but
>>> all the tutorials I can find only show examples of projects that are
>>> very small.
>>>
>>> I'm now at the stage in my project where I think I still have time to
>>> change the design if I do it in the next couple of days - otherwise
>>> I'm stuck with the approach I'm using above.
>>>
>>> I think the closest I've come to finding anything is here:
>>> http://java.sun.com/blueprints/corej2eepatterns/Patterns/
>>>
>>> ...  Though to be honest I don't really understand it. Can someone 
>>> take a look at my previous example and suggest any extra
>>> classes I should be using.  Also it would be useful if you could let
>>> me know how the existing files link up to being: DAOs, DTOs, Value
>>> Objects (same of DTO?!), and business classes.
>>>
>>> I think I'm a little confused! :os
>>>
>>> Any help would be appreciated.
>>>
>>> Tim Christopher
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
>>> For additional commands, e-mail: user-help@struts.apache.org
>>>
>>>
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
>> For additional commands, e-mail: user-help@struts.apache.org
>>
>>
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
> For additional commands, e-mail: user-help@struts.apache.org
> 
> 
> 


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

Re: Struts Approach

Posted by Erik Weber <er...@mindspring.com>.
Robert Taylor wrote:

> Tim,
>
> I think things look pretty good so far.
>
> Right now Customer is a domain object representing a customer.
> CustomerDAO is a DAO respsonible for mapping the Customer to its 
> relational counterpart(s). CustomerService collaborates with 
> CustomerDAO  to manage the persistence and data access of a Customer.
> Together these 3 classes make up what I would refer to as a 
> CustomerComponent. This simple component can be used in any of your 
> applications that interact with a customer and need simple Customer 
> CRUD (create, retrieve, update, and delete) services.
>
> I would caution you against adding any application specific logic to 
> this component as it would reduce the reusability of it in other 
> applications which you may develop which may need to use the same 
> component. I'm assuming right now your application logic mirrors the 
> services provided by the CustomerService; simple CRUD  operations. Now 
> let's say you have some additional requirements such as:
>
> - When a customer is created, notify operations.
> - When a customer is deleted, notify operations.
> - Find all the customer's who have placed orders within a specified
>   date range.
>
> You might be tempted to add this functionality to CustomerService and 
> add the supporting functionality to CustomerDAO and Customer. Now 
> let's say you need to develop another application which needs simple 
> CRUD functionality for a Customer. Ooops. You can't use CustomerService.
>
> I have found that an additional application service layer provides the 
> flexibility to add application specific logic leveraging a library of 
> components instead of modifying them. For example, you might want to 
> add a CustomerApplicationService which leverages the services provided 
> by CustomerService. So for the example provided above, the 
> CustomerApplicationService may collaborate with event listeners which 
> respond appropriately to creating and deleting a customer. It may also 
> collaborate with specialized DAO for retrieveing customer's using 
> application logic criteria. It may also collaborate with value object 
> assemblers to build value objects which cannot simply be represented 
> by a single Customer. My point is that the additional layer provides a 
> layer of abstraction which decouples the domain components from 
> application specific logic which allows you to leverage your 
> investments in these domain components, instead of modifying them to 
> support additional application requirements.


So, this additional layer, in a Struts application, resides between the 
Struts classes (Actions) and your managerial facade? The Action 
instantiates/looks up a CustomerApplicationServiceImpl, which does CRUD 
via the CustomerService component but also manages (possibly by itself, 
possibly by delegation) app-specific notification logic, high-level view 
helper logic, etc. Is this correct? Effectively then, this layer 
decouples the managerial layer from, not Struts per se (though it does 
indirectly), but, from your implementation strategy (whether you use 
passive/active notification, how you filter read results, etc.) with 
respect to the business rules. Right?

Thanks,
Erik


>
> Don't forget that CustomerApplicationService should be an interface 
> such  that it can be implemented as a POJO (plain old java object) or 
> maybe a delegate which hides a remote implementation.
>
>
>
> /robert
>
>
> Tim Christopher wrote:
>
>> Hi,
>>
>> I'm currently designing a web application and as time progresses I
>> keep on less convinced that my approach is correct.
>>
>> Applying what I have to a shop example the classes I have are:
>>
>> ------------------------------------------------------
>> * Note: I use the iBATIS framework.
>> ------------------------------------------------------
>> Customer.java
>> # Contains get + set methods using correct types, ie. name (String),
>> age (int), etc.
>>
>> CustomerDAO.java
>> # An interface for database operations for the Customer, i.e.
>> insertCustomer, updateCustomer, etc.
>>
>> CustomerSqlMapDAO.java
>> # Implements the CustomerDAO interface and effectively calls the db.
>>
>> CustomerService.java
>> # Used to gain access to CustomerDAO and CustomerSqlMapDAO.
>>
>> CustomerDispatchAction.java (ex insert method - but will contain CRUD)
>> # Gets instance of CustomerService; copies jsp form details into a
>> DynaActionForm; copy form DynaActionForm to Customer.java object;
>> calls insert method in CustomerService with Customer object as the
>> parameter; return ActionForward.
>>
>> Struts-Config.xml
>> # Contains DynaValidatorForm for storing customer details.
>> ------------------------------------------------------
>> ------------------------------------------------------
>>
>> I've tried looking through a few books and using Google for
>> information that would explain if this is the correct approach, but
>> all the tutorials I can find only show examples of projects that are
>> very small.
>>
>> I'm now at the stage in my project where I think I still have time to
>> change the design if I do it in the next couple of days - otherwise
>> I'm stuck with the approach I'm using above.
>>
>> I think the closest I've come to finding anything is here:
>> http://java.sun.com/blueprints/corej2eepatterns/Patterns/
>>
>> ...  Though to be honest I don't really understand it. 
>> Can someone take a look at my previous example and suggest any extra
>> classes I should be using.  Also it would be useful if you could let
>> me know how the existing files link up to being: DAOs, DTOs, Value
>> Objects (same of DTO?!), and business classes.
>>
>> I think I'm a little confused! :os
>>
>> Any help would be appreciated.
>>
>> Tim Christopher
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
>> For additional commands, e-mail: user-help@struts.apache.org
>>
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
> For additional commands, e-mail: user-help@struts.apache.org
>
>

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

Re: Struts Approach

Posted by Robert Taylor <64...@bellsouth.net>.
Tim,

I think things look pretty good so far.

Right now Customer is a domain object representing a customer.
CustomerDAO is a DAO respsonible for mapping the Customer to its 
relational counterpart(s). CustomerService collaborates with CustomerDAO 
  to manage the persistence and data access of a Customer.
Together these 3 classes make up what I would refer to as a 
CustomerComponent. This simple component can be used in any of your 
applications that interact with a customer and need simple Customer CRUD 
(create, retrieve, update, and delete) services.

I would caution you against adding any application specific logic to 
this component as it would reduce the reusability of it in other 
applications which you may develop which may need to use the same 
component. I'm assuming right now your application logic mirrors the 
services provided by the CustomerService; simple CRUD  operations. Now 
let's say you have some additional requirements such as:

- When a customer is created, notify operations.
- When a customer is deleted, notify operations.
- Find all the customer's who have placed orders within a specified
   date range.

You might be tempted to add this functionality to CustomerService and 
add the supporting functionality to CustomerDAO and Customer. Now let's 
say you need to develop another application which needs simple CRUD 
functionality for a Customer. Ooops. You can't use CustomerService.

I have found that an additional application service layer provides the 
flexibility to add application specific logic leveraging a library of 
components instead of modifying them. For example, you might want to add 
a CustomerApplicationService which leverages the services provided by 
CustomerService. So for the example provided above, the 
CustomerApplicationService may collaborate with event listeners which 
respond appropriately to creating and deleting a customer. It may also 
collaborate with specialized DAO for retrieveing customer's using 
application logic criteria. It may also collaborate with value object 
assemblers to build value objects which cannot simply be represented by 
a single Customer. My point is that the additional layer provides a 
layer of abstraction which decouples the domain components from 
application specific logic which allows you to leverage your investments 
in these domain components, instead of modifying them to support 
additional application requirements.

Don't forget that CustomerApplicationService should be an interface such 
  that it can be implemented as a POJO (plain old java object) or maybe 
a delegate which hides a remote implementation.



/robert


Tim Christopher wrote:
> Hi,
> 
> I'm currently designing a web application and as time progresses I
> keep on less convinced that my approach is correct.
> 
> Applying what I have to a shop example the classes I have are:
> 
> ------------------------------------------------------
> * Note: I use the iBATIS framework.
> ------------------------------------------------------
> Customer.java
> # Contains get + set methods using correct types, ie. name (String),
> age (int), etc.
> 
> CustomerDAO.java
> # An interface for database operations for the Customer, i.e.
> insertCustomer, updateCustomer, etc.
> 
> CustomerSqlMapDAO.java
> # Implements the CustomerDAO interface and effectively calls the db.
> 
> CustomerService.java
> # Used to gain access to CustomerDAO and CustomerSqlMapDAO.
> 
> CustomerDispatchAction.java (ex insert method - but will contain CRUD)
> # Gets instance of CustomerService; copies jsp form details into a
> DynaActionForm; copy form DynaActionForm to Customer.java object;
> calls insert method in CustomerService with Customer object as the
> parameter; return ActionForward.
> 
> Struts-Config.xml
> # Contains DynaValidatorForm for storing customer details.
> ------------------------------------------------------
> ------------------------------------------------------
> 
> I've tried looking through a few books and using Google for
> information that would explain if this is the correct approach, but
> all the tutorials I can find only show examples of projects that are
> very small.
> 
> I'm now at the stage in my project where I think I still have time to
> change the design if I do it in the next couple of days - otherwise
> I'm stuck with the approach I'm using above.
> 
> I think the closest I've come to finding anything is here:
> http://java.sun.com/blueprints/corej2eepatterns/Patterns/
> 
> ...  Though to be honest I don't really understand it.  
> 
> Can someone take a look at my previous example and suggest any extra
> classes I should be using.  Also it would be useful if you could let
> me know how the existing files link up to being: DAOs, DTOs, Value
> Objects (same of DTO?!), and business classes.
> 
> I think I'm a little confused! :os
> 
> Any help would be appreciated.
> 
> Tim Christopher
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
> For additional commands, e-mail: user-help@struts.apache.org
> 
> 
> 


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