CODEWITHSUNDEEP
javajakarta-eemodels
Ben
Ben

Reputation: 62454

Java packaging conventions - what about models?

I started in PHP, where packages aren't required. We're going to be building a project at my work that is in Java and I'm considering the architecture. The system will be a content management system with 3 levels. We'll have various models for all different things. Should all the models be in one package, should they be broken up into various packages grouped with all the other functionality pertaining to their "section" or something else completely?

Upvotes: 0

Views: 1188

Answers (3)

millhouse
millhouse

Reputation: 10007

If you're programming to interfaces (always a good idea for a system of any reasonable size/complexity) then a solution that often works well is having a project/package holding the interface definitions, divided up sensibly; e.g.:

  • com.mycompany.cms.domain.foo
  • com.mycompany.cms.domain.bar
  • com.mycompany.cms.domain.bar.user
  • com.mycompany.cms.domain.bar.page

This set of interfaces is used by all the layers in the system, and hopefully the actual concrete implementations can be kept "private" to a layer; for example in your Data-Access layer, you might have:

package com.mycompany.cms.dataaccess.bar.user;

import com.mycompany.cms.domain.bar.user.CMSUser;

@Entity
@Table("CMS_USER")
public class CMSUserJPA implements CMSUser {
    ...
}

which is an implementation of CMSUser that has been suitably annotated for use with a JPA data access layer.

So obviously, you'll have a certain amount of "mirroring" of the package structure of the interface project in your implementing projects - which makes it really important to get that structure right - as Sean Patrick Floyd says in another answer, you've got to find a taxonomy that is both meaningful and keeps the number of files-per-package within a workable range.

Upvotes: 3

Anderson Carniel
Anderson Carniel

Reputation: 1771

I generally separate packets of layers:

For example, model, business and visualization. Where the model is the data support, business is my program's algorithms and display screens. You can also have within these layers, support for logging, exception handling.

The creation of packages have to justify the same context of their classes. For example, it makes sense to be in the same package, classes that handle database, with classes that are views of the data.

Hope this helps

Upvotes: 0

Sean Patrick Floyd
Sean Patrick Floyd

Reputation: 299128

There are no absolute rules for this. As a rule of thumb I'd say that a package should contain no more than 10 and no less than 2 compilation units, but tastes differ. Try to find a taxonomy that lets you divide the models into several packages without feeling artificial.

But I would not put the models into the same package as code that works with them. Try to make your package names representative of what happens in them, e.g.

com.myapp.model.x
com.myapp.model.y
com.myapp.service.x
com.myapp.service.y
com.myapp.controller.x
com.myapp.controller.y

Upvotes: 3

Related Questions