-----Ursprüngliche Nachricht-----
Von: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]
Gesendet: Freitag, 21. Juni 2002 19:57
An: [EMAIL PROTECTED]
Betreff: RE: UML? File organization?
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)
-----Original Message-----
From: Kevin.Bedell [mailto:[EMAIL PROTECTED]]
Sent: Friday, June 21, 2002 1:07 PM
To: struts-user
Subject: RE: UML? File organization?
>From reviewing my UML Distilled and UML Reference manual books, here are
some thoughts -
- According to the UML reference manual, pakage design should "reflect
the
high-level architecture of a system - it's decomposition into subsystems
and their dependencies. Dependency among packages summarizes the
dependencies among the package contents".
- In "UML Distilled", Martin Fowler recommends designing packages to
minimize package dependencies. He goes as far as recommending the
designer
create "facade" classes within packages that expose only those
properties/methods that other packages need to know about. (I'm not
sure
if I buy into taking it this far.)
In other words, the idea that "Things that are used together should be
packaged together" could be thought of as another way of saying
"minimize
inter-package dependencies" which is what the UML recommends anyway.
And it also follows the idea you have below of trying to minimize
package
dependencies so that you could break pieces of the application off (or
reuse them) later. This seems to me to be sound object-oriented design -
it
encapsulates functionality into packages and minimizes dependancies (and
hopefully maintenance effort later!).
This approach is similar to approaches I've use successuflly in the
past.
Kevin
[EMAIL PROTECTED] on 06/21/2002 12:37:15 PM
Please respond to "Struts Users Mailing List"
<[EMAIL PROTECTED]>
To: [EMAIL PROTECTED], [EMAIL PROTECTED]
cc: (bcc: Kevin Bedell/Systems/USHO/SunLife)
Subject: RE: UML? File organization?
I understand what you are saying here. I the example below for the
packages where would
(1) something that cleary will be used in many packages go
(2) something that could be used in another
Would it make sense have both the way shown below and another package
for business logic
Sooo...
com.ebind.appname.req - (forms, actions, properties files, etc)
com.ebind.appname.bid
com.ebind.appname.find
com.ebind.appname.buy
com.ebind.appname.somecommonfunctions.*
com.ebind.commonstuff1
com.ebind.commonstuff2
Does that make sense?
Thanks for reminding me about the WEB-INF/JSP issues on other servers.
I remeber seeing that now
-----Original Message-----
From: husted [mailto:[EMAIL PROTECTED]]
Sent: Friday, June 21, 2002 11:18 AM
To: struts-user
Subject: Re: UML? File organization?
Personaly, I find it most useful to organize everything along
conventional functional module or package lines. Things that are used
together should be packaged together.
At some point, these functional divisions might also made into actual
Struts modules and developed independantly. (This prospect should figure
highly in any organizational scheme.)
Within any application, there are tasks that are used together and tend
to form subsystems. Often, these tasks are handled by the same
developer(s) within a larger team, and also tie into the applications
life-cycle and overall organization. For example, an auction application
might have a registeration package, a searching package, a bidding
package, and a fulfillment package.
For the JSPs, I generally use a /pages folder off the root, and then
organize by package beneath that. Something like
/pages
./reg
./bid
./find
./buy
On the Java source side, there would be corresponding .reg, .bid, .find,
and .buy packages
Which I think might all fall under your Conventional Theory category.
I believe this is also the way the Struts source files are organized.
The Action classes are all kept together, since they all work together
to form the control layer. Other classes were dispatched to the util
package (and then off to the commons). The validator has it own pacakge,
as does tiles.
We tend to put suffixes like *Action and *Form on classes, but that
stems from the *Bean naming approach, rather than the package.
Also keep in mind that organizing files for Struts is not any different
than organizing them for any Model 2/MVC architecture.
BTW, whether putting pages under is WEB-INF is "best" or not may depend
on what container you are using. It is *not* always an option. It also
means that you might have to separate your JSPs from other assets that
need to be outside of WEB-INF, like HTML files, images, and stylesheets.
Like any strategy, this approach has consequences, both good and bad.
-- Ted Husted, Husted dot Com, Fairport NY US
-- Java Web Development with Struts
-- Tel: +1 585 737-3463
-- Web: http://husted.com/about/services
[EMAIL PROTECTED] wrote:
>
> I have been playing with UML and trying to find a good way to do the
> upfront design of a struts based application. Has anyone done this
> already and have any suggestions? I know the use-cases can pretty
much
> stay the same...
>
> I am also putting together a document on the best way to go about
> struturing your directories under struts... If anyone has any
> suggestions I would love to hear it...
>
> I already have stuff like JSPs under the WEB-INF and stuff. I am
trying
> to work out the best way to organize all the packages in the src
> directory...
>
> Should they be by purpose of the objects like (conventional theory)
>
> com.ebind.hrdata.people;
> com.ebind.hrdata.companies;
> com.ebind.struts.create;
> com.ebind.struts.search;
>
> or more along the lines of struts:
>
> com.ebind.peoplefinder.search;
> com.ebind.peoplefinder.create;
>
> We've got two small projects done wth struts and the next ones will be
> more complex so I want to get the best practices down (I've printed
and
> read the husted site a few times already)
>
> Any thoughts would be great - and I will drop the document out here
when
> its done
>
> --
> To unsubscribe, e-mail:
<mailto:[EMAIL PROTECTED]>
> For additional commands, e-mail:
<mailto:[EMAIL PROTECTED]>
--
To unsubscribe, e-mail:
<mailto:[EMAIL PROTECTED]>
For additional commands, e-mail:
<mailto:[EMAIL PROTECTED]>
--
To unsubscribe, e-mail: <
mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <
mailto:[EMAIL PROTECTED]>
--
To unsubscribe, e-mail:
<mailto:[EMAIL PROTECTED]>
For additional commands, e-mail:
<mailto:[EMAIL PROTECTED]>
--
To unsubscribe, e-mail:
<mailto:[EMAIL PROTECTED]>
For additional commands, e-mail:
<mailto:[EMAIL PROTECTED]>
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
