13.3. Keep Domain Classes Separate from Others

As outlined in Chapter 12, persistent-domain classes and business-logic classes using them can technically be compiled separately, with only the persistent classes being subsequently enhanced.

The easiest way to practically achieve this is to keep two separate source directories for the two types of classes. This approach is not technically required, because it would be perfectly possible to simply compile and enhance all classes of a project, but it has several potential benefits, including the following:

• Increased build speed (even a well-written fast byte-code enhancer takes time on a large project when unnecessarily enhancing hundreds of persistent-aware classes that would not have to be enhanced; see above).

• Simplified and clearer CLI build infrastructure, for enhancement^[9] and data-store-dependant schema utility tools (most larger projects generally have non-GUI build processes, often based on Jakarta's ant, with an IDE visual interface as alternative, if at all).

  ^[9] A theoretical alternative would be to keep all source files together, and configure the byte-code enhancer to only enhance explicitly named classes. This is technically possible with the Sun RI enhancer, but many implementation-supplied enhancers will simply enhance every class file found under a certain directory.

• Simplified usage from typical Integrated Development Environments (IDEs), which would typically compile all classes contained under a source path, not generally providing a hook for enhancement, and then start the application using the non-enhanced classes.

A directory structure similar to this one may make sense:

lib/
(...)
src/
classes/
src.model/
classes.model/

In this example, the following definitions are set:

• src contains the .java source files for all non-persistent business-logic, helper, and presentation-related (e.g., Servlets, and so on) classes.

• classes contains the compiled .class files for all source files in src.

• src.model contains the .java source files for all persistent-capable (not only persistence-aware) domain model classes, as well as the respective .jdo mapping descriptors for the enhancement.

• classes.model contains the compiled and enhanced .class files of the domain model, as well as copies of the respective .jdo mapping descriptors for runtime usage.

Note by the way that when splitting Java source directories like this, classes from both locations can share (parent) packages. A directory layout like this—src/com/abc/web, src/com/abc/util, and src.model/com/abc/model (where package com.abc is compiled from two locations)—does not bother Java at all.

The following build order may then make sense, based on the assumption that domain model classes do not depend on (do not call any methods in) the src classes, because only the business-logic classes in src use the persistent domain model classes in src.model:

The first two steps should generally be performed by an ant-based build infrastructure, unless an IDE provides specific support and hooks for this purpose. The third step can also be performed by a built-in compile feature of an IDE, as long as classes.model is on the project's CLASSPATH configuration.

Note that, although it is often convenient to edit the domain model classes in src.model in the same IDE, it is important to configure an IDE to not compile and mix these classes together with the project's other code in src. An example of a typical configuration from a popular IDE is shown in Figure 13-1.