On Mon, 2005-02-28 at 12:27, Shey Rab Pawo wrote:
>
> On Mon, 28 Feb 2005 11:40:13 -0500, Mike Millson
> <[EMAIL PROTECTED]> 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
On Mon, 28 Feb 2005 11:40:13 -0500, Mike Millson
<[EMAIL PROTECTED]> 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
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
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 t
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 +, Tim Christopher
<[EMAIL PROTECTED]> wrote:
> So what you're saying is that if I
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 +, Tim Christopher
<[EMAIL PROTECTED]> wrote:
> So what you're saying is that if I include a separate DTO it doesn't
> really
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 differ
> 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? ;-)
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
t
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 poi
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
> 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
> 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:
>
> * IThisIsAVeryLongNa
> 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:
>
> * IThisIsAVeryLongNa
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 C
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
On Sat, 26 Feb 2005 06:24:06 -0700, Larry Meadors
<[EMAIL PROTECTED]> wrote:
> On Sat, 26 Feb 2005 14:13:59 +0100, <[EMAIL PROTECTED]> wrote:
> > Hmm, i thought it's more or less standart for interfaces in the advanced
> > java community...
> >
>
> Baloney.
>
> HttpServletRequest? HttpServletResp
> 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 st
> 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 Ja
> 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 Ja
On Sat, 26 Feb 2005 15:30:12 +0100, <[EMAIL PROTECTED]> 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
> Clas
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 nec
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 nec
On Sat, 26 Feb 2005 14:30:18 +0100, <[EMAIL PROTECTED]> 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),
HAHAHAH
On Sat, 26 Feb 2005 14:32:22 +0100, Leon Rosenberg
<[EMAIL PROTECTED]> wrote:
> > I am unaware of any interfaces in the JDK that are ISomething.
>
> I-terator?
>
> :-
>
> -
> To unsubscribe, e-mail: [EMAIL PROT
> I am unaware of any interfaces in the JDK that are ISomething.
I-terator?
:-
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
> I am unaware of any interfaces in the JDK that are ISomething.
I-terator?
:-
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
ng /
1.2.
Wait till 1.6 :-)
Leon
> -Ursprüngliche Nachricht-
> Von: Larry Meadors [mailto:[EMAIL PROTECTED]
> 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, &
ng /
1.2.
Wait till 1.6 :-)
Leon
> -Ursprüngliche Nachricht-
> Von: Larry Meadors [mailto:[EMAIL PROTECTED]
> 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, &
> 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:[EMAIL PROTECTED]
> > Gesendet: Samstag, 26. Febr
nd "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:[EMAIL PROTECTED]
> Gesendet: Samstag, 26. Februar 2005 14:06
> An:
nd "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:[EMAIL PROTECTED]
> Gesendet: Samstag, 26. Februar 2005 14:06
> An:
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
<[EMAIL PROTECTED]> wrote:
>
>
> <2cents>
> The inter
<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>
> 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 :-)
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 in
On Fri, 25 Feb 2005 16:27:09 -0800, <[EMAIL PROTECTED]> 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 customer
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 Cus
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
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
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*
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.
---
41 matches
Mail list logo
