Every application should be designed with a particular architectural pattern in mind so that developers know where to place their components. The application architec
ture should consider good design concepts such as loose coupling, separation of con
cerns, transaction management, reuse, and extension. A typical Spring web application can be broken down into at least three layers:
User interface —Spring MVC, JSF, Wicket, Struts, or some other web framework.
Services —Business components that expose services for the user interface layer.
Usually where transactions are defined.
Persistence—Components that access various data sources using APIs such as JDBC, object-relational mapping APIs such as Hibernate or JPA, or even messag- ing beans that access message queues via JMS.
When an application architecture is defined in layers, developers are able to switch each layer’s implementation. It becomes straightforward to switch persistence strate- gies or user interface implementations. Spring, being a component-driven develop- ment framework, fits well with layered architectures. Developers are encouraged to build beans using interface-driven development techniques, defining business method signatures in the interface, and implementing them in a realizing bean. Spring uses the interface as the contract to the client, so that the implementation can be swapped later.
Defining interfaces also helps developers test their components in isolation, using unit testing tools such as JUnit, which can use various APIs to mock or stub other beans.
1.4.1 The web layer
Spring Roo provides a Spring MVC–based web application layer. It uses annotation- driven controllers, and can integrate with traditional Spring business services or with Active Record–based entities, as you’ll see later.
Spring MVC is an MVC platform, and as such contains all of the views as well. These views are written in a variant of JavaServer Pages that is fully XML-compliant, and all JSP files are well formed. These files are known as JSPX files, and are written and saved with the .jspx extension.
Roo also deploys several major Spring MVC features, which we discuss in chapter 5:
Layout support—Roo installs the Apache Tiles framework to lay out your web applications, and separates the web pages into a header, menu, content‚ and footer.
Theming—Spring themes provide a way to present the website in several ways.
Roo installs theming support automatically.
Localization—Roo installs Spring MVC’s localization support so that you can sup- port multiple languages, allowing you to translate elements of your website so that various native language speakers can use your application.
Roo uses a set of generated tag libraries to handle operations such as displaying result lists, providing smart form elements such as drop-down pick lists, date and time pick- ers, and rich text editing. As you’ll see in chapters 6 and 7, you can customize the web- site entirely, and add support for dynamic Ajax calls or other rich components yourself.
Roo is also smart. It can generate, or scaffold, web application controllers, views‚
and logic automatically to manage your data objects. As you're about to see, it can adapt to two major forms of application architecture: services-and-repositories and Active Record.
21 Roo application architecture models
1.4.2 Service-and-repository layering in Roo
Roo can provide all of the traditional features of a typical web-based layered applica- tion. Figure 1.8 shows a fairly typical component architecture for a Spring MVC–based project.
This application diagram is constructed of several well-defined components:
Views—Components that display information or provide ways to edit data. Com- monly Java Server Pages or JSF Facelets.
Controllers —Accept incoming HTTP web requests and return responses, gener- ally using views to present the data.
Web service layer—Some applications expose web services, using a convention such as SOAP or REST. These are analogous to web controllers and views and exist in the same layer as those in this diagram.
Services—Provide an abstraction of business functionality, and are usually coarse- grained, performing a task that may interact with a number of objects in the repository layer. Transactional boundaries are usually defined in the service layer.
Repositories—At the bottom of the stack is the repository or data access layer, which communicates to the databases via JDBC, mapping tools such as iBatis/
MyBatis or‚ more commonly‚ object-relational mapping (ORM) tools such as Hibernate or JPA. Messaging integration code using APIs such as JMS may also be defined at this level.
Models/Entity classes—These components represent data that is transferred from the data access layer or service layer upward to the user interface components.
These may either be simple Java Beans—data transfer objects—or “live” objects such as JPA entities, which can be manipulated and then updated directly.
PizzaController
& views
PizzaService
PizzaRepository
Pizza (model)
PizzaController
& views
PizzaService
PizzaRepository
Pizza (model)
PizzaController
& views
PizzaService
PizzaRepository
Pizza (model)
PizzaController
& views
PizzaService
PizzaRepository
Pizza (model)
Figure 1.8 Pizza Shop as a layered architecture
Roo can operate in this traditional layered mode, using Roo entities, controllers, ser- vices‚ and repositories. You can even roll your own Spring Beans to represent each of these component types, and wire them together using Spring’s @Autowired annota- tion, or even drop down to using XML or even JavaConfig to configure them. Roo is a Spring-based platform.
Roo is an animal with a different stripe. It enables a more lightweight, rapid appli- cation development approach to Spring development that may provide for even more rapid productivity.
1.4.3 Roo’s Active Record architecture
Roo was created to allow developers of Spring applications to become even more pro- ductive, and attempt to match the rapidity of development frameworks such as Ruby on Rails or Grails, while not leaving the Java platform. Though developers can still introduce services and repositories, by default Roo takes the approach of slimming down the required components, as shown in figure 1.9.
The required components are
Views—Spring MVC views
RESTful controllers—Spring MVC controllers
Entities—Turbocharged Active Record–based entity objects, which know how to load, update, and persist themselves
At first glance, this may seem like a loss of structure. Where are the services? What about database access objects?
One of the reasons applications in enterprise Java take so long to deliver is the sheer number of artifacts required. There’s a constant push-and-pull between “getting the application out the door” and “architecting it so someone else just might under- stand it later.” Many non-Java frameworks have been able to deliver applications more quickly, with considerable maintainability, because they implement a more domain- centric view of the world. Take a look at figure 1.10.
The Active Record pattern turbocharges the persistence model by providing smart
“Roo entities”—beans wired using AspectJ ITDs (special class-like files that weave in additional functionality)—to provide service-and-repository features within a single
PizzaController
& views
ToppingController
& views
BaseController
& views
PizzaOrderController
& views
Pizza Topping Base PizzaOrder
Figure 1.9 Roo’s Active Record architecture
23 Roo application architecture models
class. This might seem counter-intuitive to a typical service-and-repository Spring developer. But consider that this pattern, the Active Record, has been used by frame- works such as Ruby on Rails and Grails with great success.
In Roo, you can define your persistence objects as Spring Roo entities, and Roo automatically wires up the code to properly validate and persist the entities for you.
You’ll see the advantages of this in the next three chapters, but for now, consider that you’re able to use this feature to reduce the amount of code you type. Who needs to write boilerplate methods to load and persist data if a tool can do it for you?
1.4.4 Which pattern is better?
You may be asking why Roo exposes two models. Actually, the original Roo platform envisioned that Active Record would take over, just as it has for those Ruby on Rails and Grails application tools.
But a large subset of Spring developers desire service-and-repository layers in their applications. Also, in most applications, there are cross-domain problems to solve—
what if you want to expose a data manipulation command that spans toppings and bases? Do you place the methods in the Base or the Topping entity? In those cases, developers would at least build a service, and call both entity manipulations behind the service.
What you use is up to you. You may find less code overall for the Active Record pat- tern, and if you have a large number of model objects that you’re manipulating, the extra work of building repositories and services for each one may be a bit tedious, especially when you aren’t doing anything special in those objects. But if you truly have cross-entity transactions and you have significant business logic, you may wish to roll out services, and if you don’t want to see your persistence logic held within your entities, you can ask Roo to create repositories.
Roo is flexible about application architecture, and, in fact, it can dynamically re-fit your project using the shell. Often, you’ll be adding fields to your entities, or adding annotations, and the Roo shell will generate code and keep up with you.
We discuss Active Record and layered service-and-repository patterns in chapters 3 and 4.
Now let’s review what you’ve learned about Spring Roo.
POJO with annotations
Persistence JavaBean
validation Bean
JPA Entity String
generation
Figure 1.10 Roo’s
“turbocharged” entity