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