A friendly place for programming greenhorns!
Big Moose Saloon
Register / Login
Win a copy of
PostGIS in Action
this week in the
JDBC and Relational Databases
Java Advanced Topics Training
Java in General
Architect Certification (SCEA/OCMJEA)
Part II- package structure
Joined: Apr 01, 2002
Feb 14, 2005 18:52:00
For packaging the classes, here are the two approches I am thinking.
1) grouping them by tiers.
and for JSPs, : web.fbn.jsp.xxxx
2) other approach is package by usecases. Classes related to usecase are kept under package like : com.fbn.login.api.*****
Can anyone suggest, which one is better? I am inclining more towards First approach.
[ February 14, 2005: Message edited by: Prasad Kuppa ]
Joined: Feb 18, 2005
Feb 18, 2005 05:20:00
I am also having similar thoughts like u on the
Joined: Feb 13, 2004
Feb 18, 2005 09:05:00
I would suggest:
Divide the application into top level packages based on the functionality. Then divide each of the package into tier level packages.
There is a nice article out there at Sun's website about breaking down the application into packages.
You can also have top level breakup on the basis of tiers and then second level breakup on the basis of functional modules.
I do not think it is a good idea to map package structure to use case. It may result in mushroom growth of packages.
Joined: Oct 19, 2002
Nov 16, 2005 19:45:00
I spent some time searching with Google...but could not find the article.
If anyone does know of any Sun article that explains best practices on
packaging (I mean com.companyname.xxx packaging and not WAR/JAR/EAR packaging)...do let me know !.. Thanks a lot.
Looks like there's still no confident/best practice answer in this thread...
I agree. Here's the link:
subject: Part II- package structure
Breakng bond in Notice period in [ company X ] please help its urgent
Should we depict session facade and application service in the class diagram?
Problem with accessing servlet from browser
All times are in JavaRanch time: GMT-6 in summer, GMT-7 in winter
| Powered by
Copyright © 1998-2015