The typical Model layer of a correctly designed MVC application can be broken down into three
conceptual sublayers. Each sublayer can be thought of as a component or responsibility of the
Model. Figure 4-1 illustrates this breakdown.
Figure 4-1: Model layer breakdown
Each sublayer does not necessarily represent a separate set of classes, but rather the Model's set of responsibilities. You may choose to house a specific function's code for all layers in one large class, or you may break down each sublayer into fine-grained objects. The level of object
granularity is up to you, and what's best and/or necessary really depends on the size and complexity of your application. The following are the three sublayers:
External interface Composed of code that provides an interface that external code uses to interact with the Model.
Business logic Encompasses the bulk of the Model code and provides the business functionality for an application.
Data access Composed of code for communicating with an application's data sources such as a database.
Struts and the Model
The Struts framework does not provide any specific features or constraints for developing the Model layer of your application. At first glance this may seem odd, or even a shortcoming, given that Struts is designed for building MVC applications. However, it's actually a key design feature
of Struts and is a great benefit. By not dictating how the Model layer should be built, Struts gives your application the flexibility to use any approach or technology for building the Model layer code. Whether it be an Object-Relational Mapping (ORM) framework (e.g., Hibernate or TopLink), Enterprise JavaBeans (EJB), Java Data Objects (JDO), or the Data Access Objects (DAO) pattern, Struts will accommodate.
Because the Model defines the business logic, the Model is where Struts ends and your application code begins. Your Model code will be accessed from subclasses of the Struts Action object that are part of the Controller layer of the Struts framework. Action subclasses interact
with the Model via interfaces and use its Data Transfer Objects to pass and retrieve data.
You should not place any business logic or data access code in Action objects. Doing so would
bypass the separation of the Model and the Controller. Similarly, your Model code should not
have any references to Struts code or objects. Violating this rule unnecessarily couples your core
application code to Struts.