struts-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ted Husted <hus...@apache.org>
Subject Re: UML? File organization?
Date Fri, 21 Jun 2002 20:23:51 GMT
You can probably do both. 

The resuable portions of the dao can go into 

	com.ebind.projects.dao

and any specific subclasses can go into 

	com.ebind.myapp.billing.dao

If you can get away with having all your dao generic, then, sure use the
former. But if you are using a "blackbox" desingn, you might need to
subclass something in [com.ebind.projects.dao], which would beg the
existance of [com.ebind.myapp.billing.dao]. In practice, there might be
only one class in something like com.ebind.myapp.billing.dao (but a very
important one!). 

-T.

wbchmura@Ensign-BickfordInd.com wrote:
> 
> I don't think I would say it was my idea...  I think it was either in my
> UML user guide book or java patterns...
> 
> This is all well and good, and I could walk away nodding my head saying
> "yeah that sounds good"...
> 
> but now in practice with struts, etc...
> 
> The app I am planning now is a web app that will track:
> * Projects - (add a project, alter status, close projects, add notes)
> * Billing - Enter in a billable time entry, generate reports, etc
> * Ticket Tracking - typical functionality for a ticket system (add,
> edit, assign, close, notify problem reports)
> ... Lets stop there for now...
> 
> So the functionality of the system is pretty clearly broken out into the
> above groups.  We can package them like so into
> 
> com.ebind.myapp.projects
> com.ebind.myapp.billing
> com.ebind.myapp.tickets
> 
> So now we can break them up inside each one into:
> 
> com.ebind.myapp.projects.dao
> com.ebind.myapp.projects.logic
> com.ebind.myapp.projects.struts.createnew
> com.ebind.myapp.projects.struts.edit
> com.ebind.myapp.projects.struts.report
> 
> com.ebind.myapp.billing.dao
> com.ebind.myapp.billing.logic
> com.ebind.myapp.billing.struts.addEntry
> com.ebind.myapp.billing.struts.report
> 
> com.ebind.myapp.tickets.dao
> com.ebind.myapp.tickets.logic
> com.ebind.myapp.tickets.struts.createnew
> com.ebind.myapp.tickets.struts.edit
> com.ebind.myapp.tickets.struts.archive
> 
> Alternatively, we could break out the logic so that it was more
> re-useable...
> 
> com.ebind.projects.dao
> com.ebind.projects.logic
> com.ebind.myapp.tickets.struts.createnew
> com.ebind.myapp.tickets.struts.edit
> com.ebind.myapp.tickets.struts.archive
> 
> ??and potentially add factory objects to the project??
> com.ebind.myapp.tickets.logic (objects in here)
> 
> I used the term logic here to represent the business logic that controls
> all behind the scenes
> 
> So this seems to satisfy:
> (1) Keeping the struts together, keeping the logic togther
> (2) Packaging by functionality
> (3) cross package dependencies can be done (or implement a facade)
> (4) logic would have the beans for a given app (not form beans)
> 
> On the JSP side:
> 
> /jsp/projects
> /jsp/billing
> /jsp/tickets
> /images
> 
> Depending on the complexity, the different areas could be broken up
> further (ie: /projects/create, /projects/reports, etc)
>

--
To unsubscribe, e-mail:   <mailto:struts-user-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:struts-user-help@jakarta.apache.org>


Mime
View raw message