General Refactorings J2EE

Separate Data Access Code

Data access code is embedded directly within a class that has other unrelated responsibilities.

Extract the data access code into a new class and move the new class logically and/or physically closer to the Data Source.

Separate Data Access Code

Separate Data Access Code

Motivation

Create cleaner abstractions, increase cohesion, and reduce coupling, thus improving modularity and reusability.

Mechanics

  • Identify and extract the data access logic from the controller object.
  • Use Extract Class to create a new class and move data access code from the original class into the new Data Access Object (DAO) class.
  • Consider including the DAO as part of the name of the new class in order to flag its role as a Data Access Object.
  • Use the new DAO from the controller to access data.

Example

Consider an example where a servlet has embedded data access code to access some user information. Applying the first two bullets, assume we change the design, as shown in Figure .

Separate Data Access Code – Servlet example

Separate Data Access Code – Servlet example

We now have two classes: one for the servlet, which acts as a controller, and the other a new object called “UserDAO,” which acts as a data access object to access user information. The UserDAO encapsulates all Java Database Connectivity (JDBC) code and decouples the servlet from the implementation details. The servlet code is much simpler as a result.

Consider another example where the persistence logic is embedded in an enterprise bean using bean-managed persistence. Combining the persistence code with the enterprise bean code creates brittle, tightly coupled code. When the persistence code is part of the enterprise bean, any change to the persistence store requires changing the bean's persistence code. Such coupling has a negative impact on enterprise bean code maintenance. This is another example of how this refactoring can help.

Applying this refactoring, we change the design as shown in Figure .

Separate Data Access Code – Enterprise bean example

Separate Data Access Code – Enterprise bean example

Refactor Architecture by Tiers

Increasing architectural sophistication requires changing the localization of data access logic and processing logic.

Move Data Access code logically and/or physically closer to the actual Data Source.
Move processing logic out of the client and presentation tiers into the business tier.

Refactor Architecture by Tiers

Refactor Architecture by Tiers

Motivation

Separate Data Access Code demonstrates refactoring data access logic, while this refactoring discusses other types of business logic in an application.

The J2EE platform offers clear separation of concerns into the roles of servlets, JSPs, and EJB components to provide maximum benefits in terms of scalability, flexibility, transactions, security, and so forth.

As business requirements become more sophisticated, the design needs to better address issues related to persistence, transactions, security, and scalability of business services. At some point in this increasing complexity, session beans and entity beans are introduced to provide centralized business processing for all clients and to leverage the benefits of the EJB container.

Some designers use heavyweight components like enterprise beans without ensuring that the application requirements warrant their use. Some sophisticated application requirements that influence this decision are transactions, security, scalability, and distributed processing.

Mechanics

  • Separate data access code from control and entity objects into data access objects.
  • Separate presentation and business processing. Introduce session beans for business processing. Retain presentation processing in servlets and JSPs.
  • Apply this step when application requirements become more sophisticated, and as business logic consolidation is required at the business tier to offer the same business service to all clients (i.e., not only to presentation clients).
  • Introducing session beans as business service processing components enables this functionality. Session beans access the persistent storage via the data access objects.
  • Container-managed or bean-managed transaction demarcation can be utilized as appropriate for the session beans.
  • Introduce entity beans to model-shared, transactional, coarse-grained persistent business objects. If requirements do not warrant using entity beans, then skip this step.
  • Apply this step when the persistent business components become increasingly complex and you wish to leverage the entity bean benefits, including container-managed transactions and container-managed persistence (CMP).
  • Entity beans offer container-managed transaction for transaction demarcation. This allows declarative programming for transaction demarcation without hardcoding the transaction logic into the enterprise beans.
  • Decouple presentation-tier and business-tier components, using business delegates.
  • Business Delegate decouples the presentation-tier components from business-tier components and hides the complexity of lookup and other implementation details.

Use A Connection Pool

Database connections are not shared. Instead, clients manage their own connections for making database invocations.

Use a Connection Pool to pre-initialize multiple Connections, improving scalability and performance.

Use A Connection Pool

Use A Connection Pool

Motivation

Opening a connection to a database is a fairly expensive operation that takes time and resources to perform. Both performance and scalability are affected. Since database connections are limited, if each client manages its own connection, the total number of connections will likely be exhausted far sooner than desired.

This issue arises in the presentation tier on projects that use a phased approach to introducing EJB technology. In this case, components in the presentation tier initially interact directly with a database, and the data access code is later moved into the business tier and encapsulated in an EJB layer.

Mechanics

  • Create an interface for connection management, including methods for retrieving and returning a connection.
  • Apply Extract Class and/or Move Method, moving the existing connection retrieval code into a class that implements the connection management interface.
  • At the points from which the connection code was extracted, substitute invocations to an instance of this new class; that is,
    connectionMgr.getConnection() and
    connectionMgr.returnConnection(conn)
  • Note that the JDBC specification, version 2, includes a standard mechanism for introducing connection pooling. This mechanism, if available, is the recommended way to introduce connection pooling. In the JDBC specification version 2, the management interface is named javax.sql.DataSource and it provides a factory for pooled Connection objects.
    • At this point, only the structure and interface has been standardized, but the functionality is the same.
    • Still no pooling is implemented, unless the JDBC 2.0 DataSource factory is utilized, which is recommended.
    • Modify the implementation of the connection retrieval methods within the connection manager implementation to pre-initialize some Connection instances and share them among users, thus introducing pooling.
    • There are numerous publicly available implementations from which to choose.
    • Clients of these connection manager instances are typically DAOs.
    • Data access code typicall

Face Book Twitter Google Plus Instagram Youtube Linkedin Myspace Pinterest Soundcloud Wikipedia

All rights reserved © 2018 Wisdom IT Services India Pvt. Ltd DMCA.com Protection Status

J2EE Topics