General J2EE: Structuring and naming packages in J2EE apps

  1. Structuring and naming packages in J2EE apps (4 messages)

    Hi, I've been searching for quite a while now but have yet to find a "best practice" for structuring and naming packages in J2EE applications. A number of articles go into detail about how the code should be separated into layers (i.e. presentation, business, persistence etc...) but I can't seem to find any consistency with respect to package naming/structuring. I would like to know what people have used that they feel works well i.e. for clarity and easy maintenance. Where do you put your view-related classes (i.e. Struts actions), you persistence related classes (i.e. dao) etc. Thanks. FYI: I'm using Struts+Spring+iBatis
  2. You have to clearly and completely separate the UI layer, Business Service Layer, and the Persistence layer. Struts handles the UI layer, Spring managed objects handle the Business logic layer, and Spring managed DAO-iBatis objects handle the Data Persistence layer. The basic principle is that UI layer does not know anything how the data is actually retrieved or saved, and Data persistence layer does not know where the data it is providing is actually displayed to users. The Business Service Layer actually maps to the Use Cases you created. Let's say, you have two use cases, first is retrieve all monthly transaction, and second is update transaction. So, you will have at least two methods in your business service object. You are using Spring, right? So you can utilize Spring Transaction Manager for iBatis. You can also integrate the Struts with the Spring as well, if you want to. The objects you get from the Data Persistence layer might be wrapped in such a way by the Business Layer objects (remember that the UI layer refers only to the Interface of the objects, not the actual implementation class) so that that objects really represent the use cases. The DAO layer only has insert, update, delete, view methods for each of the related table. The UI layer only has methods related to UI navigation. Remember that within one UI method, there should be only one data update method call to Business layer object, and one or more data retrieval method calls. Why? Coz you want to have atomic transaction, right?. Now, about the package names: You can start the package name with you company name, in reverse order, i.e. com.mycompany. Then you add the project name, i.e. myproject. Then you add the layer name, i.e. ui or service or dao. Then you add the module name, i.e. payroll. Well, the followings are the package names convention: 1. UI -> com.mycompany.myproject.ui.[module] 2. Service -> com.mycompany.myproject.service.[module] 3. DAO -> com.mycompany.myproject.dao.[module] Regards, Fernando Karnagi
  3. Hi Fernando, Thanks for the reply. Where would you put your value objects or data transfer objects? Also, don't you find it a little redundant to repeat the module name in each package layer?
  4. There are two approaches, as I explained to you earlier. You can directly pass the value objects retrieved from the Persistence Layer back to UI layer, or, you can wrap those objects into other objects relevant to business case (combining two objects,or more into one big objects). I don't think it is redundant to repeat module name in each package layer, coz, when you are designing multi-layer modules, you have to be aware that your module might be used by others. Hope this will help. Regards, Fernando Karnagi
  5. doubt : dao structuring[ Go to top ]

    well i agree with your structuring for ui layer, service layer but according to the dao design pattern it is based on abstract factory pattern where you specify the dao you want and it provides you the dao object. it is left to the pattern to decide how to fetch the object so we actually dont require to create a seperate package structure for resolving. Another reason is that dao are mostly associated with the domain objects like CustomerDAO, ItemDAO, SupplierDAO etc and the domain objects themselves are not segregated according to the modules. modules may share the domain objects similarly they may share the dao also therefore i think the package structure for the dao should just be


    and there should also be a different packaging for the domain and dto



    please respond