wood burning stoves 2.0*
The moose likes EJB and other Java EE Technologies and the fly likes Best practices for organizing packages in J2EE application Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Murach's Java Servlets and JSP this week in the Servlets forum!
JavaRanch » Java Forums » Java » EJB and other Java EE Technologies
Bookmark "Best practices for organizing packages in J2EE application" Watch "Best practices for organizing packages in J2EE application" New topic
Author

Best practices for organizing packages in J2EE application

Siddharth Naik
Ranch Hand

Joined: Apr 09, 2006
Posts: 35
What are some of the best options for organizing packages in a J2EE application?

I did some googling to find the answer but most of the pages talked about over all directory structure of J2EE applications and not how specific packages within src directory should be organized. Here are a few options I am aware of based on my work experience at a few organizations.

----------------------------------------------------------------------------------------

Option 1: organize based on technical artifacts

com.mycompany.bo (includes files like: Customer.java, CreaditCard.java, Account.java, Promotion.java)
com.mycompany.services (includes files like: UserManaer.java, Authorization.java, Accounting.java, DiscountManager.java)
com.mycompany.actions (includes files like: Login.java, Authorize.java, AccountLookup.java, CalculateDiscount.java)
com.mycompany.dto
com.mycompany.assemblers

Pros: intuitive package structure; I know how the code would look like in each package
Cons: If I am debugging a business issue then it's hard to find out which packages might be involved

----------------------------------------------------------------------------------------

Option 2: organize based on business concerns

com.mycompany.customer (includes files like: Customer.java,UserManaer.java,LoginAction.java)
com.mycompany.payment (includes files like: CreaditCard.java, Authorization.java,Authorize.java)
com.mycompany.account (includes files like: Account.java,Accounting.java,AccountLookupAction.java)
com.mycompany.promotion (includes files like: Promotion.java,DiscountManager.java,CalculateDiscount.java)

Pros: everything related to customer is in one package so it's easy to figure out business dependency
Cons: My technical artifacts are divided across packages and I don't know what each file might contain without opening it

----------------------------------------------------------------------------------------

Option 3: Organize based on both - the business concerns and the technical artifacts

com.mycompany.beans.customer
com.mycompany.services.customer
com.mycompany.actions.customer
com.mycompany.beans.account
com.mycompany.services.accounts
com.mycompany.actions.accounts
...
...


Pros: clear separation both business wise and tech wise
Cons: too many packages and sometimes only one file in each package


How's it organized at your company and how do you like it? What would you recommend as the best option?

Thanks,
Sid


Thanks<br />Sid
Jeff Koester
Greenhorn

Joined: May 12, 2010
Posts: 2
We use option 1 at our organization, organize based on technical artifacts. This is also what I have typically seen other places. You know how every class in the package should be coded. I have not experienced any issues debugging business issues. Normally you know what service or action is involved and go from there. A problem with option 2 is sometimes classes, such as business objects, are shared between business processes, so which package would these objects be put under. I have never seen option 3, that sounds like way too many packages.
 
 
subject: Best practices for organizing packages in J2EE application
 
Similar Threads
What it takes to be an architect?
ICE Test 286 solved 89 %
test 286 q&a pass 88% (can someone tell me where I was wrong)
Does anyone solved ICE Test 286, 287 100% ?
Where to put the business logic?