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]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
