Re: [OT] Re: Struts Approach
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, [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), 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Struts Approach
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Struts Approach
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 +, Tim Christopher
[EMAIL PROTECTED] 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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[OT] Re: Struts Approach
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:[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, [EMAIL PROTECTED] 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:[EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[OT] Re: Struts Approach
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:[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, [EMAIL PROTECTED] 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:[EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Struts Approach
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]
Re: Struts Approach
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 PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [OT] Re: Struts Approach
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), 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Struts Approach
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
Re: Struts Approach
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Struts Approach
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Struts Approach
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 wa 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
Re: Struts Approach
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 wa 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
Re: Struts Approach
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 +, Tim Christopher [EMAIL PROTECTED] 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- No one ever went blind looking at the bright side of life. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Struts Approach
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
