Questions about package naming conventions for enterprise level application
801540Jan 12 2011 — edited Jan 12 2011I am trying to come up with a sensible package structure, but I need some help:
So far I have this:
com
+---mycompany
+---application
¦ +---myapplication
¦ +---core
¦ ¦ +---printsupport
¦ +---data
¦ +---admin
¦ +---dept1
¦ +---dept2
¦ +---dept3
¦ +---dept4
¦ +---dept5
¦ +---dept6
¦ +---dept7
¦ +---utilities
¦ +---view
¦ +---admin
¦ +---dept1
¦ +---dept2
¦ +---dept3
¦ +---dept4
¦ +---dept5
¦ +---dept6
¦ +---dept7
¦ +---utilities
+---component
+---viewport
+---gestures
+---layout
Data access is going into a package named: com.mycompany.appiication.myapplication.data
The View layer is going into a package named: in com.mycompany.application.myapplication.view.
As you can see, both packages are broken down into specific departments. This doesn't look correct.
Data access will be handled with Hibernate.
Questions:
1) Is "view" the best thing to call my view layer, or is there something better?
2) I have specific departments under view and data, but this does not seam right. Can someone sugest a better way to organize view, data, and domain specific packages?
3) I need a place for business logic. Should I put it within View, or should I create another package? What is a good name for a package that holds business logic?
4) How are domain objects named relative to hibernate data access objects. For example, I have a Hibernate object named Well which maps to a database table named Well. However, I also have a domain object named Well, which contains business logic. What is the best way to handle this?
Does anyone have examples that I could look at, or suggestions?
Thanks.