> 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
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
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 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]
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
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
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*
18 matches
Mail list logo
