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 +0000, 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]
