Specifically, the following conditions make pagination necessary:

• Screen real estate is limited. Your JSP/client UI may have insufficient space to display the entire results at once and your user may not be able to find what he or she wants quickly in a very large data set.


• Your resources are pooled or constrained. Result sets are too large to be managed reasonably within your connection and memory limitations.

Paging Strategies That Work

Basic querying and paging strategies can start out simple but quickly lead to disaster if you fail to consider query evolution and data growth. Open-ended or unbounded queries that perform well over small test data sets may degrade sharply against real data. If you don't manage your precious DBMS and memory resources, your problems will only compound under load.

Efficient data retrieval and paging is a trade-off between memory usage and response-time requirements. Broadly speaking, most roll-your-own J2EE paging mechanisms fall into two basic categories:

• Cache based: Results are cached for fast access in subsequent pages.


• Query based: Results are fetched from the DBMS on demand as the user pages.

Cache-based approaches cache the query results over and above what the database provides, in an intermediate tier (on the HTTP session, in the server using a Stateful Session Bean or in a home-grown cache). Subsequent page requests hit the cache rather than the database. Such cache-based mechanisms are memory intensive and work well for low-volumes, recurring queries, and small to medium-sized result sets. The cache-hit rates are high and the I/O overheads are low, yielding good response times.

Query-based approaches don't use caches. They deliver pages on demand, direct from the DBMS to the client. They service additional pages by issuing more queries to the DBMS rather than pulling data from a cache. These approaches discard or skip unwanted rows from previous or future pages using low-level JDBC functions and context information from the last fetched page. Query-centric paging is memory efficient but requires additional round trips to the database, leading to slightly slower response times overall.

More sophisticated mechanisms adopt a hybrid approach. They constrain cache sizes by caching a fixed number of pages ahead, maintaining bounded cache windows, and using efficient query mechanisms and offline threads to backfill the results transparently to the client.

Caching vs. Query Trade-offs

Cache-based approaches are fast, but they have a few pitfalls. For example, unbounded or open-ended queries for large result sets can lead to uncontrolled memory growth as the results are serialised and cached. Large result sets take a long time to service and take up valuable connection and session resources. Whenever a connection is consumed for long periods of time, the number of connections available in your J2EE shared connection pool is effectively reduced. To cope with high load, your system should aim to service your requests as quickly as possible. If your requests take a long time to process, your overall throughput will drop. You don't want to occupy your resources with long-lived queries, because you won't have any connections and threads left to do anything else.

Long-lived queries can also lead to connection timeouts if your query takes more time to execute than your preset JDBC connection time limit allows. Avoid this in cache-based strategies by narrowing or constraining your search criteria so that your DBMS queries (and results) are bounded.

Caching is most beneficial when the cached data is hit repeatedly. However, if your user searches are consistently yielding distinct results, your caches can't be reused across requests. Worse, if the user rarely pages beyond the first page, your caching within the session is for naught. You should carefully manage caches so that they don't grow too large and they expire promptly when they're no longer required.

Hybrid or query-based approaches are more reliable than cache-based alternatives. They have slightly slower response times but can scale transparently for large result sets and high request volumes. An unbounded query will take a long time to execute but won't exceed your memory constraints or take too long to execute. The DBMS connection is relinquished once the required data (usually the first one or two pages) has been fetched. This means that the connection is held for the bare minimum before being returned to the connection pool. The only downside is that additional context information must be passed back and forth on your page requests.

Table 1 lists the issues you need to consider when deciding on a paging approach.

One way to guarantee that you never assemble or read redundant data is to manipulate the WHERE clause on your search query to explicitly exclude data that you don't need. In other words, you narrow the query to the requested page. This approach requires that you pass additional context information back and forth on your page requests. This is so that the paging mechanism can adjust the queries automatically to account for data that's already been fetched.

Your page query should be carefully constructed to account for the following:

• Paging direction: Forward/next or back/previous


• Search criteria: Whether entered by the user or as part of your normal business use case


• The target page: Return rows for the requested page only


• Page size: Number of rows in a page

Paging direction is important if you want to be able to scroll both forwards and backwards across your result data. Caching as you go can provide back functionality. However, this works well only for static data. If your data is volatile, your cache data may be out of date by the time you page back. The only way to guarantee correct results is to issue another query to fetch the previous page of data. For cacheless paging, this means using SQL ORDER BY and WHERE clauses. If one or more ORDER BY columns specify the forward paging order, you can page backwards by reversing the ORDER BY directions in conjunction with the appropriate WHERE clause.

Basic business data searches usually entail some sort of dynamic WHERE clause construction so that user-entered criteria may be incorporated in the query. With query-based paging, the WHERE clause includes the search criteria as well as additional semantics to narrow the result set to the correct page. Use row identifiers to limit and qualify your page (see Figure 1). A row identifier uniquely identifies a row in a result set and consists of one or more columns from the result set. Think of it as a logical index into you result set.

Figure 1: Query-based Paging Using Row Identifiers

Typically, your row ID can be a primary key. However, depending on the data, it may be a combination of primary key columns and/or other columns. A page is denoted by a start and end row ID pair: the first row and last row in the page, respectively. To page forward (next), adjust the query to fetch all rows where the row ID is greater than the last row ID of the current page. To page back, query for all rows where the row ID is less than the first row ID of the current page.

This mechanism works fine for single-column, simple row IDs and ascending forward paging order, but searches are rarely that simple. In some cases, the row ID is a combination of columns and normal forward paging direction is a mixture of ascending (ASC) and descending (DESC) ORDER BY columns. The trick is to ensure that all your ORDER BY columns are included in the WHERE clause (including the row ID columns) and all the row ID columns are included in the ORDER BY, adjusted for forwards (paging next) and backwards (paging back) ordering.

Row-ID-based Paging Algorithm

Take a basic query example that selects three columns, col1 (VARCHAR), col2 (INTEGER), and col3 (TIMESTAMP), from table foo. To fetch the first page, issue the following SQL:

SELECT 	col1,

col2,

		col3 

FROM 	foo 

WHERE  	col1=? 

ORDER BY 	col2 ASC ,col3 DESC 

In this example, the search criteria supplied by the user is applied to col1. The row ID is comprised of col1 and col2, and the normal forward paging order is defined as col2 ascending and col3 descending.

JDBC provides a function to limit the number of rows returned for a query, Statement::setMaxRows(int max). To fetch the first page, simply issue the basic query and set the max rows to your page size. Use this for every paging query as it guarantees that you fetch only one page of data for any given request. For optimum performance, use Statement::setFetchSize(int rows) to set the fetch size to match the page size. This guarantees that the page will be fetched in one low-level IO request between the driver and the DBMS.

To fetch the next page, adjust the WHERE clause to exclude the first page by fetching all rows that match the search criteria and that are logically greater than the last row ID of the first page. The row ID part of the WHERE clause is constructed from the specified row ID columns (col2 and col3) for the query, and the row ID values are substituted from the first page.

Fetch the next page:



SELECT 	col1,

col2,

		col3 

FROM 	foo 

WHERE  	col1=?  AND 

		( (col2 >  ?  )  OR  (col2 = ?  AND col3 <  ?  )  )  

ORDER BY 	col2 ASC ,col3 DESC 

To fetch the previous page, flip the ORDER BY's to fetch backwards and adjust the WHERE clause to exclude unwanted rows by fetching rows that are logically less than the row ID of the first row of the current page.

Fetch the previous page:



SELECT 	col1,

col2,

		col3 

FROM 	foo 

WHERE  	col1=?  AND ( (col2 <  ?  )  OR  (col2 = ?  AND col3 >  ?  )  )  

ORDER BY 	col2 DESC ,col3 ASC 

In your Java code, ensure that you reorder the results to normal forward ordering before serving the page to the client.

This paging algorithm works seamlessly for very large result sets and arbitrarily complicated or unbounded queries, provided you use the JDBC Statement::setMaxRows() function and construct the WHERE and ORDER BY clauses appropriately. For optimum performance, insure that your WHERE clause columns are indexed.

One way to set up this framework is to adopt a configuration-driven or declarative approach in which you pre-define the search as a logical paginated view in a properties file and supply the actual search parameters at runtime with the request. In your configuration file, you can make the view explicitly identify the row IDs, ORDER BY columns, and any other information deemed necessary for your paging implementation. To issue a search, the caller doesn't have to do any fancy SQL footwork. It just identifies and loads the desired view using the view's unique identifier and then issues the search/fetch request along with any user-supplied criteria.

A view is just a logical window across one or more physical DBMS tables and views. A paginated view is a view that contains additional discriminating information (such as row IDs) that enables it to be paged. Configure your paginated view in a properties file and define the forward paging direction (ORDER BY's) and row ids.

The following steps walk you through the creation of a paging component. For a complete package of all the required Java classes, download the source code.

Step 1. Create/configure your paginated view

# Example view

example.view=foo

example.pagesize=5

example.where=col1=?

example.rowids=col2 ASC,col3 DESC

Step 2. Create a class to represent your view, PageDefn


Create a Java class (PageDefn) to represent your paginated view. You can either load it from your properties file or create it on the fly in your code. Configuration is the preferred approach, as the caller doesn't have to know about the view internals or table meta-data. Your PageDefn contains all the information relevant to your paginated view and is responsible for handling the SQL construction details:

public class PageDefn extends ViewDefn {



	public interface PageAction {

		public static final int FIRST = 0;

		public static final int NEXT = 1;

		public static final int PREVIOUS = 2;

		public static final int CURRENT = 3;

	}



	protected int pageSize;

	protected ColumnDesc[] rowIds;





	public PageDefn() {

		super();

		rowIds = null;

		pageSize = 50;





	}



	public PageDefn(String viewname) {

		super(viewname);

		rowIds = null;

		pageSize = 50;

	}



...



}

Step 3: Create a paging data access object (DAO)


Create a special-purpose PagingDAO (see Listing 1: PageDefn.java) that supports parameter substitution and uses Prepared statements. Prepared statements are faster than normal queries as they can be pre-compiled by the DBMS. Your PagingDAO executes the paging query and handles the results. The actual SQL construction is delegated to the PageDefn. This separation of concerns allows you to evolve the PageDefn and its subclasses to support more sophisticated query configuration independently of the DAO.

Ensure that your DAO closes all database resources (ResultSets, Statements, and Connections) once the query has been executed. Put your close code inside a FINALLY clause so that your resources will close even when an exception is thrown.

Step 4. Create a PageContext and Page command


Create a PageCommand class to encapsulate your page request and hold the results. Client servlets and actions will use the PageCommand to interact with your paging framework. Your command should provide methods to do the following:

• Specify the target view (PageDefn)


• Supply optional search criteria (query parameters)


• Specify the page action (FIRST, CURRENT, NEXT, or BACK)


• Access the page results

In addition, your PageCommand should encapsulate any context information required by the paging implementation to support your paging algorithm. Create a context object that holds your paging request action and results, and encapsulates your paging internals:

public class PageContext implements Serializable {



	protected Object page; // results

	protected Object firstEntry; //  first row ID 

	protected Object lastEntry; // last row id

	protected int action; // paging action

	protected PageContext prevContext; // previous context state





	public PageContext() {

		this.page = new Object[0];

		this.firstEntry = null;

		this.lastEntry = null;

		this.action = PageDefn.PageAction.FIRST;

	}



	public Object[] getPage() {

		return ((Collection) page).toArray();

	}



	public void setPage(Object page) {

		this.page = page;

	}



	public int getAction() {

		return action;

	}



	

	public void setAction(int action) {

		this.action = action;

	}

}

Ensure that your PageContext object is Serializable, as it will be passed on the wire back and forth between the Servlet and middle tiers.

Create your PageCommand class to encapsulate your paging requests, and include the PageContext as a member variable:

public class PageCommand extends ViewCommand {



	protected PageContext context;



...



}

The PageCommand class is just a data transfer object (DTO) that conveys request parameters and holds page results. Page data and row-IDs are held inside the PageContext object. The caller doesn't have to know about the PageContext attribute directly except to remember to re-use it across page requests for a given read request.

Step 5. Create a PagingService


Create a specialized paging service (see The COR Pattern Puts Your J2EE Development on the Fast Track for more information on COR services and configuration) for handling PageCommand requests. It will process PageCommands and pass them to the PagingDAO for processing:

public class PageService implements Service {



	

	public Command process(Command command) throws ServiceException {

		if (!command.getClass().equals(PageCommand.class)) {

			return null;

		}



		PageCommand pcmd = (PageCommand) command;



		PageContext context = pcmd.getContext();

		PageDefn desc = (PageDefn) pcmd.getDefn();



		// Get A DAO    

		PagingDAO dao = PagingDAO.get();

		// Issue Query, results are set into the context by the DAO

		try {



			dao.executeQuery(desc, context, true);

			return pcmd;

		} catch (DAOException e) {

			throw new ServiceException(e);

		}



	}



}

Step 6. Exercise your Page command!


To fetch the first page, create an instance of PageCommand, load your target view, set any user-supplied parameters and page action, and issue the command to the CORManager. The CORManager will transparently route the command to the PageService to handle:

// load view and set user supplied criteria

PageDefn d = PageDefnFactory.getPDF().createPageDefn(bundle,view);

d.setParams(new Object[] { criteria });

PageCommand cmd = new PageCommand(d);



// fetch the first page

cmd.setAction(PageDefn.PageAction.FIRST);

cmd = (PageCommand) CORManager.get().process(cmd);



// process results

PageContext context = cmd.getContext();



// Process results

Object[] rows = cmd.getContext().getPage();

if (rows == null) return;

for (int i = 0; i < rows.length; ++i) {

	System.out.println("ROW(" + i + ") " + rows[i].toString());

}



// cache context to be reused for subsequent pages..

getServletContext().setAttribute("context",cmd.getContext());

To fetch the next page, insure that you reuse the PageContext from the previous request. The PageContext contains all the information the paging mechanism needs for qualifying your queries. If you're managing the paging from the servlet tier, cache the PageCommand/PageContext object on the HttpSession so that you can reuse it when the user pages forward or back:

// Create PageDefintion

..

PageDefn d = PageDefnFactory.getPDF().createPageDefn(bundle, view);



// Retrieve context from ServletContext

PageContext c = (PageContext) getServletContext().getAttribute("context");



// Create Page Command  

PageCommand cmd = new PageCommand(d,c);

cmd.setAction(PageDefn.PageAction.NEXT);

cmd = (PageCommand) CORManager.get().process(cmd);



// cache result on servlet context

getServletContext().setAttribute("context",cmd.getContext());

...

The first page will be slightly slower to fetch than other pages. However, your UI will be able to accurately show the total number of pages returned, as well as the current page number. If page count isn't important or the data is so volatile that the total page count isn't reliable, avoid the overhead altogether by skipping the count query.

To add page number and total page count support to your paging mechanism, extend the PageContext object to store and maintain page counts and extend the PagingDAO to issue an additional count query on receipt of a FIRST page request.

Paging in Perspective

Searching and querying over data is an integral part of most Web sites. Paging is an ideal way to manage limited server resources, large result sets, and congested UI real estate. The approach you chose, whether cache-based, query-based, or hybrid, depends on your use cases and data characteristics. Regardless, you should limit your memory and connection usage so that your paging architecture can scale efficiently to meet your performance targets.

ISO-8859-1

ISO8859_1

ISO 8859-1, 라틴 알파벳 No. 1

ISO-8859-2

ISO8859_2

라틴 알파벳 No. 2

ISO-8859-4

ISO8859_4

라틴 알파벳 No. 4

ISO-8859-5

ISO8859_5

라틴/키릴 문자 알파벳

ISO-8859-7

ISO8859_7

라틴/그리스 문자 알파벳

ISO-8859-9

ISO8859_9

라틴 알파벳 No. 5

ISO-8859-13

ISO8859_13

라틴 알파벳 No. 7

ISO-8859-15

ISO8859_5

라틴 알파벳 No. 9

KOI8-R

KOI8_R

KOI8-R, 러시아어

US-ASCII

ASCII

American Standard Code for Information Interchange

UTF-8

UTF8

8 비트 UCS Transformation Format

UTF-16

UTF-16

16 비트 UCS Transformation Format, 옵션의 바이트순서 마크에 의해 식별되는 바이트순서

UTF-16BE

UnicodeBigUnmarked

16 비트 Unicode Transformation Format, 빅 endian 바이트순서

UTF-16LE

UnicodeLittleUnmarked

16 비트 Unicode Transformation Format, little endian 바이트순서

windows-1250

Cp1250

Windows 동구

windows-1251

Cp1251

Windows 키릴 문자

windows-1252

Cp1252

Windows 라틴 문자-1

windows-1253

Cp1253

Windows 그리스 문자

windows-1254

Cp1254

Windows 터키어

windows-1257

Cp1257

Windows 발트제어

이용할 수 없다

UnicodeBig

16 비트 Unicode Transformation Format, 빅 endian 바이트순서, 바이트순서 마크 첨부

이용할 수 없다

UnicodeLittle

16 비트 Unicode Transformation Format, little endian 바이트순서, 바이트순서 마크 첨부

Big5

Big5

Big5, 중국어 (번체자)

Big5-HKSCS

Big5_HKSCS

Big5 (홍콩의 확장 첨부), 중국어 (번체자, 2001 개정을 짜넣어)

EUC-JP

EUC_JP

JISX 0201, 0208, 0212, EUC 인코딩, 일본어

EUC-KR

EUC_KR

KS C 5601, EUC 인코딩, 한국어

GB18030

GB18030

중국어 (중공에서 정식으로 쓰는 약자체?), 중화 인민 공화국 표준

GB2312

EUC_CN

GB2312, EUC 인코딩, 중국어 (중공에서 정식으로 쓰는 약자체?)

GBK

GBK

GBK, 중국어 (중공에서 정식으로 쓰는 약자체?)

IBM-Thai

Cp838

IBM 타이 확장 SBCS

IBM00858

Cp858

Cp850 의 확장으로 유로 문자를 포함한다

IBM01140

Cp1140

Cp037 의 확장으로 유로 문자를 포함한다

IBM01141

Cp1141

Cp273 의 확장으로 유로 문자를 포함한다

IBM01142

Cp1142

Cp277 의 확장으로 유로 문자를 포함한다

IBM01143

Cp1143

Cp278 의 확장으로 유로 문자를 포함한다

IBM01144

Cp1144

Cp280 의 확장으로 유로 문자를 포함한다

IBM01145

Cp1145

Cp284 의 확장으로 유로 문자를 포함한다

IBM01146

Cp1146

Cp285 의 확장으로 유로 문자를 포함한다

IBM01147

Cp1147

Cp297 의 확장으로 유로 문자를 포함한다

IBM01148

Cp1148

Cp500 의 확장으로 유로 문자를 포함한다

IBM01149

Cp1149

Cp871 의 확장으로 유로 문자를 포함한다

IBM037

Cp037

미국, 캐나다 (2 개국어, 프랑스어), 네델란드, 포르투갈, 브라질, 오스트레일리아

IBM1026

Cp1026

IBM 라틴 문자-5, 터키

IBM1047

Cp1047

라틴 문자-1 (EBCDIC 호스트용)

IBM273

Cp273

IBM 오스트리아, 독일

IBM277

Cp277

IBM 덴마크, 노르웨이

IBM278

Cp278

IBM 핀란드, 스웨덴

IBM280

Cp280

IBM 이탈리아

IBM284

Cp284

IBM 카타로니아어/스페인, 스페인어권라틴 아메리카

IBM285

Cp285

IBM 영국, 아일랜드

IBM297

Cp297

IBM 프랑스

IBM420

Cp420

IBM 아라비아어

IBM424

Cp424

IBM 헤브라이어

IBM437

Cp437

MS-DOS 미국, 오스트레일리아, 뉴질랜드, 남아프리카

IBM500

Cp500

EBCDIC 500V1

IBM775

Cp775

PC 발트제어

IBM850

Cp850

MS-DOS 라틴 문자-1

IBM852

Cp852

MS-DOS 라틴 문자-2

IBM855

Cp855

IBM 키릴 문자

IBM857

Cp857

IBM 터키어

IBM860

Cp860

MS-DOS 포르투갈어

IBM861

Cp861

MS-DOS 아이슬랜드어

IBM862

Cp862

PC 헤브라이어

IBM863

Cp863

MS-DOS 캐나다계 프랑스어

IBM864

Cp864

PC 아라비아어

IBM865

Cp865

MS-DOS 북유럽

IBM866

Cp866

MS-DOS 러시아어

IBM868

Cp868

MS-DOS 파키스탄

IBM869

Cp869

IBM 근대 희랍어

IBM870

Cp870

IBM 다언어 라틴 문자-2

IBM871

Cp871

IBM 아이슬랜드

IBM918

Cp918

IBM 파키스탄 (우르두어)

ISO-2022-CN

ISO2022CN

ISO 2022 CN 형식의 GB2312 및 CNS11643, 중공에서 정식으로 쓰는 약자체? 및 번체자 중국어 (Unicode 에의 변환만)

ISO-2022-JP

ISO2022JP

ISO 2022 형식의 JIS X 0201, 0208, 일본어

ISO-2022-KR

ISO2022KR

ISO 2022 KR, 한국어

ISO-8859-3

ISO8859_3

라틴 알파벳 No. 3

ISO-8859-6

ISO8859_6

라틴/아라비아어 알파벳

ISO-8859-8

ISO8859_8

라틴/헤브라이어 알파벳

Shift_JIS

SJIS

Shift-JIS, 일본어

TIS-620

TIS620

TIS620, 타이

windows-1255

Cp1255

Windows 헤브라이어

windows-1256

Cp1256

Windows 아라비아어

windows-1258

Cp1258

Windows 베트남어

windows-31j

MS932

Windows 일본어

x-Big5_Solaris

Big5_Solaris

Big5 (Solaris zh_TW.BIG5 로케일용의 7 개의 추가 Hanzi 표의 문자 매핑 첨부)

x-euc-jp-linux

EUC_JP_LINUX

JISX 0201, 0208, EUC 인코딩, 일본어

x-EUC-TW

EUC_TW

CNS11643 (Plane 1-7, 15), EUC 인코딩, 중국어 (번체자)

x-eucJP-Open

EUC_JP_Solaris

JISX 0201, 0208, 0212, EUC 인코딩, 일본어

x-IBM1006

Cp1006

IBM AIX 파키스탄 (우르두어)

x-IBM1025

Cp1025

IBM 다언어 키릴 문자: 불가리아, 보스니아, 헤르체고비나, 마케도니아 ( 구유고슬라비아 마케도니아 공화국)

x-IBM1046

Cp1046

IBM 아라비아어 - Windows

x-IBM1097

Cp1097

IBM 이란 (현대 페르시아어)/페르시아어

x-IBM1098

Cp1098

IBM 이란 (현대 페르시아어)/페르시아어 (PC)

x-IBM1112

Cp1112

IBM 라트비아, 리투아니아

x-IBM1122

Cp1122

IBM 에스토니아

x-IBM1123

Cp1123

IBM 우크라이나

x-IBM1124

Cp1124

IBM AIX 우크라이나

x-IBM1381

Cp1381

IBM OS/2, DOS 중국 (중화 인민 공화국)

x-IBM1383

Cp1383

IBM AIX 중국 (중화 인민 공화국)

x-IBM33722

Cp33722

IBM-eucJP - 일본어 (5050 의 슈퍼 세트)

x-IBM737

Cp737

PC 그리스 문자

x-IBM856

Cp856

IBM 헤브라이어

x-IBM874

Cp874

IBM 타이

x-IBM875

Cp875

IBM 희랍어

x-IBM921

Cp921

IBM 라트비아, 리투아니아 (AIX, DOS)

x-IBM922

Cp922

IBM 에스토니아 (AIX, DOS)

x-IBM930

Cp930

UDC 4370 문자를 포함한 일본어 카타카나 한자, 5026 의 슈퍼 세트

x-IBM933

Cp933

UDC 1880 문자를 포함한 한국어, 5029 의 슈퍼 세트

x-IBM935

Cp935

UDC 1880 문자를 포함한 중공에서 정식으로 쓰는 약자체? 중국어 호스트, 5031 의 슈퍼 세트

x-IBM937

Cp937

UDC 6204 문자를 포함한 번체자 중국어 호스트, 5033 의 슈퍼 세트

x-IBM939

Cp939

UDC 4370 문자를 포함한 일본어 라틴 문자 한자, 5035 의 슈퍼 세트

x-IBM942

Cp942

IBM OS/2 일본어, Cp932 의 슈퍼 세트

x-IBM942C

Cp942C

Cp942 의 확장

x-IBM943

Cp943

IBM OS/2 일본어, Cp932 및 Shift-JIS 의 슈퍼 세트

x-IBM943C

Cp943C

Cp943 의 확장

x-IBM948

Cp948

OS/2 중국어 (대만), 938 의 슈퍼 세트

x-IBM949

Cp949

PC 한국어

x-IBM949C

Cp949C

Cp949 의 확장

x-IBM950

Cp950

PC 중국어 (홍콩, 대만)

x-IBM964

Cp964

AIX 중국어 (대만)

x-IBM970

Cp970

AIX 한국어

x-ISCII91

ISCII91

인도어파 ISCII91 인코딩

x-ISO2022-CN-CNS

ISO2022_CN_CNS

ISO 2022 CN 형식의 CNS11643, 번체자 중국어 (Unicode 로부터의 변환만)

x-ISO2022-CN-GB

ISO2022_CN_GB

ISO 2022 CN 형식의 GB2312, 중공에서 정식으로 쓰는 약자체? 중국어 (Unicode 로부터의 변환만)

x-iso-8859-11

x-iso-8859-11

라틴/타이어 알파벳

x-JISAutoDetect

JISAutoDetect

Shift-JIS, EUC-JP, ISO 2022 JP 의 검출 및 변환 (Unicode 에의 변환만)

x-Johab

x-Johab

한국어, Johab 캐릭터 세트

x-MacArabic

MacArabic

Macintosh 아라비아어

x-MacCentralEurope

MacCentralEurope

Macintosh 라틴 문자-2

x-MacCroatian

MacCroatian

Macintosh 크로아티아어

x-MacCyrillic

MacCyrillic

Macintosh 키릴 문자

x-MacDingbat

MacDingbat

Macintosh Dingbat

x-MacGreek

MacGreek

Macintosh 희랍어

x-MacHebrew

MacHebrew

Macintosh 헤브라이어

x-MacIceland

MacIceland

Macintosh 아이슬랜드어

x-MacRoman

MacRoman

Macintosh Roman

x-MacRomania

MacRomania

Macintosh 루마니아

x-MacSymbol

MacSymbol

Macintosh 심볼

x-MacThai

MacThai

Macintosh 타이

x-MacTurkish

MacTurkish

Macintosh 터키어

x-MacUkraine

MacUkraine

Macintosh 우크라이나

x-MS950-HKSCS

MS950_HKSCS

Windows 번체자 중국어 (홍콩의 확장 첨부)

x-mswin-936

MS936

Windows 중공에서 정식으로 쓰는 약자체? 중국어

x-PCK

PCK

Solaris 판의 Shift_JIS

x-windows-874

MS874

Windows 타이어

x-windows-949

MS949

Windows 한국어

x-windows-950

MS950

Windows 번체자 중국어

IoC is not a new concept, however. It has been around for several years now. Using object-oriented design principles and features such as interface, inheritance, and polymorphism, the IoC pattern enables better software design that facilitates reuse, loose coupling, and easy testing of software components. This article discusses IoC and demonstrates how to use this pattern in your software design without having to implement any of the open source frameworks.

IoC Design Pattern

Assume Class A has a relationship with Class B: it wants to use the services of Class B. The usual way to establish this relationship is to instantiate Class B inside Class A. Though this approach works, it creates tight coupling between the classes. You can't easily change Class B without modifying Class A. To eliminate the coupling, you can have a Configurator inject the instance of Class B (Object "b") to the instance of Class A (Object "a"). If you want to change the implementation of Class B later on, you simply change the Configurator object. So, the control of how Object "a" gets the reference of Object "b" is inverted. Object "a" is not responsible for getting the reference to Object "b". Instead, the Configurator is responsible for it. This is the basis for the IoC design pattern.

Figure 1. Object "a" Directly Creates Object "b"

To demonstrate the benefits of the Configurator object in this case, the following examples show a simple design without IoC and one with IoC (click here to download the sample code for this article).

Listing 1 and Figure 1 are simple examples in which Class A uses Class B:

public class A{

  private B b;



  public A(){

    b=new B();

}



Listing 1. Class A Directly Refers Class B 

Listing 1 assumes the following design decisions:

1. Class A needs a reference to Class B.


2. Class B is a concrete class that has a default constructor.


3. Class A owns the instance of class B.


4. No other class can access the instance of Class B.

Figure 2. Object "a" First Creates Object "c" and Then Object "b" by Passing Object "c"

If any one of the above design decisions change, then the code in Listing 1 must be modified. For example, if Class B changed to have a non-default constructor, which takes Class C (see Figure 2), then Listing 1 would change to Listing 2.

public class A{

  private B b;



  public A(){

   C c=new C();

    b=new B(c);

}



Listing 2. Class A Directly Refers Class B and Class C 

Once again, Listing 2 assumes certain design decisions. Now Object "a" owns both Object "b" and Object "c". If Class B or Class C changes at all, then Class A needs to change as well. In essence, a simple design of a simple class with implicit design assumptions becomes a maintenance nightmare in the future. Consider how difficult making changes would be if you had this scenario in a typical application with several classes.

Alternatively, if you use a framework that uses the IoC pattern, the responsibility of creating Object "b" moves from Object "a" to the IoC framework, which creates and injects Object "b" into Object "a". This insulates Class A from the changes in Class B. Before Object "a" is used, it needs the reference to Object "b". The IoC framework will inject Object "b" into Object "a".

Figure 3. IoC Framework Creates Object "b" and Sets It to Object "a"

Listing 3 shows Class A from the previous listings modified to use the IoC pattern.

public class A{

  private B b;



  public A(){

  }

 

  public setB(B b){

   this.b=b;

 } 



}



Listing 3. Class A Gets the Reference to Class B via setB 

Listing 3 assumes the following design decisions:

1. A needs a reference to B, and it doesn't need to know how B is instantiated.


2. B can be an interface, an abstract class, or a concrete class.


3. Before the instance of Class A is used, it needs a reference to the instance of Class B.

From the above design decisions, you can see that there is no tight coupling between Class A and Class B. Both can be changed independently without affecting each other. Of course, if there is any change in the public methods of Class B, Class A needs to change as well. But how Object "b" is created and managed is not decided in the implementation of Object "a". Instead, the IoC framework uses the setB() method in Object "a" to inject Object "b" (see Figure 3).

Setter-Based IoC

This type of IoC uses a setter method to inject the referenced object into a referring object. This is the most common type of IoC, and both Spring and PicoContainer implement it. Setter-based IoC is good for objects that take optional parameters and objects that need to change their properties many times during their lifecycles. Its main disadvantage is that you need to expose all the properties of an object to the outside world when using a setter method. This breaks one of the key OO principles: data encapsulation and information hiding.

Constructor-Based IoC

This type of IoC uses a constructor to set the reference of the object. Its main advantage is that only the creator knows about the referenced object. Once the object is created, the client code that uses the object is unaware of the referenced object. This approach may not work in all types of applications, however. For example, if you use an external API that needs a default constructor, then you need to go with a setter-based IoC. A constructor-based IoC is the main type of implementation in Spring.

Interface-Based IoC

In this type of IoC, objects implement a specific interface from the IoC framework, which the IoC framework will use to properly inject the objects. One of the main advantages of this type is that it doesn't need an external configuration file to configure the object references. Since you need to use the IoC framework's marker interface, the IoC framework knows how to glue the objects together. It is similar to using EJB. Any EJB container knows how to instantiate your objects and hook them with itself. The main disadvantage of this approach is that the marker interface ties your application to a specific IoC framework. Apache Avalon is based on this approach but this project has been closed.

An Example of IoC

If you are starting a new project, you can choose any of the open source IoC frameworks based on your needs. If you want to use the IoC pattern in your existing project then you need to write your own classes that support IoC. Though the open source frameworks offer off-the-shelf components and may provide many more features than your own implementation, you can still develop a set of classes that support the IoC pattern. This section demonstrates how.

Say you want to write a CustomerService object to process customer data. Assume customer data is stored in two different places: a relational database and an XML file. You also want to have CustomerService create Customer objects by reading data from either the database or the XML file. Now, say you want to accomplish this without changing the source code of CustomerService to switch between the database and XML file.

DataSource

First, design an interface (see Listing 4) and define common methods, which you will use to retrieve and store customer data. Both XMLDataSource and JDBCDataSource classes implement this interface.

public interface DataSource {

        public Object retrieveObject();

        public void setDataSourceName(String name);

        public String getDataSourceName();

        public void storeObject(Object object);

}



Listing 4. Common Interface to Customer Data 

XMLDataSource

Listing 5 shows a class that implements DataSource and provides an implementation that uses an XML file to retrieve and store customer data.

public class XMLDataSource implements DataSource {

        private String name;

        

/**

         * Default Constructor

         */

        public XMLDataSource() {

                super();

        }



        /**

         * Retrieve Customer data from XML Source and construct

         * Customer object

         */

        public Object retrieveObject() {

                //get XML data, parse it and then  construct

                //Customer object 

                return new Customer("XML",10);

        }

        

        /**

         * Set the DataSource name

         */

        public void setDataSourceName(String name) {

                this.name=name;                

        }



        /**

         * Return DataSource name

         */

        public String getDataSourceName() {

                return name;

        }



        /**

         * Store Customer into XML file

         */

        public void storeObject(Object object) {

                //Retrieve customer data and store it in 

                //XML file

                

        }



}



Listing 5. Class to Retrieve Customer Data from XML File 

RelationalDataSource

The class in Listing 6 also implements DataSource and provides the same implementation as XMLDataSource with only one difference: this class retrieves and stores customer data using a relational database.

public class RelationalDataSource implements DataSource {

        private String name;

        

        /**

         * Default constructor

         */

        public RelationalDataSource() {

                super();

        }



        /**

         * Using the DataSource retrieve data for Customer and build a 

         * Customer object to return it to the caller

         */

        public Object retrieveObject() {

                //get data for Customer object from DB and create a 

                //Customer object

                return new Customer("Relational",10);

        }



        /**

         * Set the DataSource name

         */

        public void setDataSourceName(String name) {

                this.name=name;                

        }



        /**

         * Return the name of the DataSource

         */

        public String getDataSourceName() {

                return name;

        }



        /**

         * Store Customer into relational DB

         */

        public void storeObject(Object object) {

                //store the customer data into Relational DB

                

        }



}





Listing 6. Class to Retrieve Customer Data from Relational DB 

public class Customer {

        private String name;

        private int age;

        

        /**

         * Default Constructor

         */

        public Customer(String name, int age) {

                this.name=name;

                this.age=age;



        }



        /**

         * @return Returns the age.

         */

        public int getAge() {

                return age;

        }

        /**

         * @param age The age to set.

         */

        public void setAge(int age) {

                this.age = age;

        }

        /**

         * @return Returns the name.

         */

        public String getName() {

                return name;

        }

        /**

         * @param name The name to set.

         */

        public void setName(String name) {

                this.name = name;

        }

}



Listing 7. Class That holds Customer Data 

CustomerService

This class in Listing 8 has a reference to DataSource, which it uses to retrieve and store Customer objects. The actual implementation of DataSource will be either XMLDataSource or RelationalDataSource, which will be injected into the CustomerService object. The constructor of the CustomerService object accepts a concrete implementation of the DataSource object and uses it to retrieve and store customer data.

public class CustomerService {

        private DataSource dataSource;

        private Customer customer;

        

        /**

         * Constructor in which DataSource object is injected. Based on the 

         * ioc.properties this object can either refer to RelationlDataSource or 

         * XMLDataSource

         */

        public CustomerService(DataSource dataSource) {

                super();

                this.dataSource=dataSource;

                customer=(Customer)dataSource.retrieveObject();

        }



        /**

         * Modify Customer name 

         * @param name

         */

        public void updateCustomerName(String name) {

                customer.setName(name);

        }

        

        /**

         * Modify Customer age

         * @param age

         */

        public void updateCustomerAge(int age){

                customer.setAge(age);

        }

        

        /**

         * 

         * @return Customer name

         */

        public String getCustomerName(){

                return customer.getName();

        }

        

        /**

         * 

         * @return Customer age

         */

        public int getCustomerAge(){

                return customer.getAge();

        }

        

}



Listing 8. CustomerService Class That Gets DataSource Reference via ServiceConfigurator 

Figure 4. IoC Using ServiceConfigurator

ServiceConfigurator

The ServiceConfigurator in Listing 9 is a main class that uses the IoC pattern to inject the concrete implementation of DataSource into the CustomerService object. It reads the configuration parameters (see Figure 4) from the ioc.properties file and decides to create either an XMLDataSource or a RelationalDataSource object. The DataSource object is created using its default Constructor, and the name of the DataSource is set using its setter method. The created DataSource object is injected into CustomerService using its constructor, which accepts a DataSource reference. The created CustomerService object is stored in the ServiceConfigurator registry so that it will be returned when a subsequent request comes for the CustomerService object.

Figure 4 shows the inner workings of ServiceConfigurator, and Figure 5 shows the UML diagram for all of the classes explained previously. You can switch between XMLDataSource and RelationalDataSource just by editing the ioc.properties file.

public class ServiceConfigurator {

        public static final String IoC_CONFIG_FILE="ioc.properties";

        private Properties props;

        private HashMap serviceRegistery;

        private static ServiceConfigurator thisObject;

        

        /**

         * This method first checks if there is a ServiceConfigurator instance

         * exist, if not creates a one, stored it and returns it

         * @return

         */

        public static ServiceConfigurator createServiceConfigurator(){

                if(thisObject==null){

                        thisObject=new ServiceConfigurator();

                }

                return thisObject;

        }

        

        /**

         * Private Constructor makes this class singleton

         */

        private ServiceConfigurator() {

                        props = new Properties();

                        serviceRegistery=new HashMap();                

                        loadIoCConfig();

                        createServices();

        }

        

        /**

         * Load the IoC_CONFIG_FILE properties file

         *

         */

        public void loadIoCConfig(){

                InputStream is = this.getClass().getClassLoader().getResourceAsStream(IoC_CONFIG_FILE);

        try {

            props.load(is);

            is.close();

        } catch (FileNotFoundException e) {

            e.printStackTrace();

        } catch (IOException e) {

                e.printStackTrace();

        }

        }

        

        /**

         * Create the CustomerService by getting the DataSource name from the

         * properties file. The CustomerService object is stored in the

         * serviceRegistery so that it will be retrieved when requested. 

         * During the construction of CustomerService the DataSource object

         * is injected into it. So the CustomerService can access the DataSource

         * to retrieve the Customer.

         *

         */

        public void createServices(){

                String dataSourceName=props.getProperty("dataSource");

                DataSource dataSource=null;

                if(dataSourceName!=null){

                        try {

                                dataSource=(DataSource)Class.forName(dataSourceName).newInstance();

                        } catch (InstantiationException e) {

                                e.printStackTrace();

                        } catch (IllegalAccessException e) {

                                e.printStackTrace();

                        } catch (ClassNotFoundException e) {

                                e.printStackTrace();

                        }

                }

                //name of the DataSource is retrieved from the properties file

                dataSource.setDataSourceName(props.getProperty("name"));

                CustomerService customerService=new CustomerService(dataSource);

                serviceRegistery.put(CustomerService.class,customerService);

        }

        /**

         * Stored Service is retrieved from serviceRegistery for the given

         * Class object

         * 

         * @param classObj

         * @return

         */

        public Object getService(Class classObj){

                return serviceRegistery.get(classObj);

        }

        

}





Listing 9. ServiceConfigurator that Uses IoC to Inject DataSource into CustomerService 

Figure 5. ServiceConfigurator UML Class Diagram

The ServiceConfigurator is a simple class that supports the IoC pattern. You can modify it to add more features such as simultaneously supporting multiple DataSource objects, dynamically injecting the DataSource into CustomerService, and life cycle management.

CustomerServiceTester

The class in Listing 10 is a JUnit test that uses CustomerService. It uses ServiceConfigurator to retrieve the CustomerService object, which is used to change the Customer name and age.

public class CustomerServiceTester extends TestCase{

        private ServiceConfigurator serviceConfig;

        

        /**

         *Default Constructor 

         */

        public CustomerServiceTester() {

                super();

        }

        

        /**

         * Create ServiceConfigurator

         */

        public void setUp() throws Exception{

                super.setUp();

                serviceConfig=ServiceConfigurator.createServiceConfigurator();

        }

        /**

         * Test CustomerService and check for Customer

         * @throws Exception

         */

        public void testCustomerService() throws Exception{

                CustomerService custService=(CustomerService)serviceConfig.getService(CustomerService.class);

                assertNotNull(custService);

                custService.updateCustomerAge(30);

                custService.updateCustomerName("Mani");

                assertEquals(30,custService.getCustomerAge());

                assertEquals("Mani",custService.getCustomerName());



                

        }





Listing 10. JUnit Test that Uses CustomerService 

So, what is the advantage of using Service Locator instead of ServiceConfigurator? ServiceConfigurator frees CustomerService from either acquiring or instantiating the DataSource directly. This makes CustomerService easy to test: simply inject the appropriate DataSource into it. More over, as explained previously in Listing 1 and Listing 2, because you do not make any assumptions about how CustomerService will get the DataSource reference, you can reuse the CustomerService object in different applications. This is the main advantage of using Service Configurator over Service Locator.

What to Inject?

In Figure 5, you see that CustomerService has a relationship with both the DataSource and the Customer classes. Yet this discussion has been about how to inject DataSource into CustomerService. Why not inject Customer into CustomerService? In fact, it is perfectly legitimate to make the ServiceConfigurator inject the Customer object into CustomerService by creating an interface for Customer and referencing it in CustomerService. It all depends on your application requirements and how you want to design the CustomerService class. The previous example made DataSource responsible for creating and storing the Customer object and created a tight coupling between DataSource and Customer. In the future, any change in the Customer class will require changes to all of the implementations of DataSource. However, the design decision was made with the assumption that the public methods of Customer would not undergo any changes, and if any changes occurred in the internals of Customer, then they will not affect the DataSource.

The only anticipated change is how the Customer data is retrieved and stored. Currently, the Customer data is stored in a relational database or in an XML file. Perhaps in the future, it might be stored in an object database or retrieved via a Web service. In either scenario, you can have new classes retrieve and store Customer data. So, based on these assumptions, the example injects only the DataSource into CustomerService, which is used to retrieve and store Customer data.

Add on to Simple Example

This article discussed the IoC pattern and briefly discussed open source frameworks that use it. It also discussed how you could incorporate the IoC pattern in your existing applications using the ServiceConfigurator example. Though simple, the ServiceConfigurator class supports the IoC pattern and provides all of its benefits. You can modify the ServiceConfigurator to add more features as you need for your applications.