Java packaging conventions - what about models?

Question

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?

score 3 · Accepted Answer · answered Dec 16 '11 at 00:40

3

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

answered Dec 16 '11 at 00:40

Sean Patrick Floyd

292,901
67
465
588

Just curious, what do you mean by 'compilation units'? I haven't heard that term before – Hunter McMillen Dec 16 '11 at 00:42
1

A compilation unit is a .java file, which may contain one or more classes, enums and interfaces. – Sean Patrick Floyd Dec 16 '11 at 00:45
Not awfully familiar to me either - I've only come across the terminology in Java parsers, not a day-to-day term. – Danny Thomas Dec 16 '11 at 00:46
It seems like horrible practice to put multiple classes within the same file 90% of the time. Does that sound accurate? Also, I'm aware what controllers and models are, but what are you defining as a service? – Ben Dec 16 '11 at 00:49
@Webnet a) More like 60%, I'd say. There are some valid uses. b) Read this question about the contrast betrween controllers and the service layer: http://stackoverflow.com/questions/3885675/service-layer-and-controller-who-takes-care-of-what – Sean Patrick Floyd Dec 16 '11 at 00:53
Should I prefix classes as well... meaning if I have a `Product` model and a `Product` controller, should I call them `ProductModel` and `ProductController` ? – Ben Dec 16 '11 at 00:54
@Webnet I'd say yes, but that's the kind of stuff that's liable to start flame wars :-) – Sean Patrick Floyd Dec 16 '11 at 00:55

millhouse · Answer 2 · 2011-12-16T02:52:37.727

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.

score 0 · Answer 3 · answered Dec 16 '11 at 00:43

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

Java packaging conventions - what about models?

3 Answers3