Developing with POJOs: faster and easier - POJOs in Action: Developing Enterprise Applications with Lightweight Frameworks - page 20

<<interface>>
TransferFacade

TransferResult transfer(fromId, toId, amount)

TransferFacadeImpl

BankingTransaction transfer(fromId, toId, amount)

<<interface>>
Transaction
Repository

TransferService

findRecentTxns()

BankingTransaction transfer(fromId, toId, amount)

Banking
Transaction

Account TransferResult

Figure 1.4 The design of TransferFacade , which encapsulates the business logic and
detaches objects

we have a design that is easier to understand, maintain, and extend. In addition,
the edit-compile-debug cycle is extremely short. We now have an application
where most of the code is sufficiently modular that you can write unit tests. We
haven't yet discussed how to eliminate the TransferService EJB . Even though it is
a simple class that calls the object model classes, development slows down consid-
erably any time we have to change it because of the deployment requirement.
Let's see what we can do about that.
Although session beans support distributed applications, the main reason they
are used in many applications is because they provide container-managed trans-
actions. The EJB container automatically starts a transaction when a business
method is invoked and commits the transaction when the method returns. It
rolls back the transaction if a RuntimeException is thrown. Container-managed
transactions are extremely useful. They free you from writing error-prone code to
manually manage transactions. Consequently, if you want to replace session
beans with POJO s, you should use an equally convenient mechanism to manage
transactions. This naturally takes us to the Spring framework.