1. 소속패키지 : org.springframework.samples.jpetstore.domain.logic
2. 상속받는 인터페이스 : PetStoreFacade.java, OrderService.java
3. 잡담
PetStoreFacade와 PetStoreImpl의 관계는 Facade패턴의 관계이다.
이는 PetStoreImpl에 정의된 다음의 메소드로 무엇을 하려는 인터페이스인지 짐작이 가능하다.
서로 다른 Dao객체를 통해 Order정보를 저장하는 메소드이다.
이 메소드를 호출하는 클래스에서는 단지 Order객체를 저장하라는 명령만 내리면 된다.
나머지 어떤 테이블에 어떻게 저장하는지는 이 메소드에서 알아서 처리한다는 내용이다.
클래스를 만든 사람이 할 말이 더 많을테니 PetStoreImpl에 주석으로 달려있는 내용을 읽어보자.
주석에 나와 있듯이 org.springframework.samples.jpetstore.service.JaxRpcOrderService 클래스를 보면 장문의 내용이 기재되어 있다.
이는 PetStoreImpl에 정의된 다음의 메소드로 무엇을 하려는 인터페이스인지 짐작이 가능하다.
·미리보기 | 소스복사·
- public void insertOrder(Order order) {
- this.orderDao.insertOrder(order);
- this.itemDao.updateQuantity(order);
- }
이 메소드를 호출하는 클래스에서는 단지 Order객체를 저장하라는 명령만 내리면 된다.
나머지 어떤 테이블에 어떻게 저장하는지는 이 메소드에서 알아서 처리한다는 내용이다.
클래스를 만든 사람이 할 말이 더 많을테니 PetStoreImpl에 주석으로 달려있는 내용을 읽어보자.
/**
* JPetStore primary business object.
*
* <p>This object makes use of five DAO objects, decoupling it
* from the details of working with persistence APIs. Thus
* although this application uses iBATIS for data access,
* another persistence tool could be dropped in without
* breaking this class.
*
* <p>The DAOs are made available to the instance of this object
* using Dependency Injection. (The DAOs are in turn configured
* using Dependency Injection.) We use Setter Injection here,
* exposing JavaBean setter methods for each DAO. This means there is
* a JavaBean "property" for each DAO. In this case the properties
* are write-only: there is no getter method to accompany the
* setter methods. Getter methods are optional: implement them
* only if you want to expose access to the properties in your
* business object.
*
* <p>There is one instance of this class in the JPetStore application.
* In Spring terminology, it is a "singleton". This means a
* per-Application Context singleton. The factory creates a single
* instance; there is no need for a private constructor, static
* factory method etc as in the traditional implementation of
* the Singleton Design Pattern.
*
* <p>This is a POJO. It does not depend on any Spring APIs.
* It's usable outside a Spring container, and can be instantiated
* using new in a JUnit test. However, we can still apply declarative
* transaction management to it using Spring AOP.
*
* <p>This class defines a default transaction attribute for all methods.
* Note that this attribute definition is only necessary if using Commons
* Attributes auto-proxying (see the "attributes" directory under the root of
* JPetStore). No attributes are required with a TransactionFactoryProxyBean,
* as in the default applicationContext.xml in the war/WEB-INF directory.
*
* <p>The following attribute definition uses Commons Attributes attribute syntax.
* @@org.springframework.transaction.interceptor.DefaultTransactionAttribute()
*
* @author Juergen Hoeller
* @since 30.11.2003
*/
OrderService라는 인터페이스는 리모트 서비스를 위해 정의했다고 한다.* JPetStore primary business object.
*
* <p>This object makes use of five DAO objects, decoupling it
* from the details of working with persistence APIs. Thus
* although this application uses iBATIS for data access,
* another persistence tool could be dropped in without
* breaking this class.
*
* <p>The DAOs are made available to the instance of this object
* using Dependency Injection. (The DAOs are in turn configured
* using Dependency Injection.) We use Setter Injection here,
* exposing JavaBean setter methods for each DAO. This means there is
* a JavaBean "property" for each DAO. In this case the properties
* are write-only: there is no getter method to accompany the
* setter methods. Getter methods are optional: implement them
* only if you want to expose access to the properties in your
* business object.
*
* <p>There is one instance of this class in the JPetStore application.
* In Spring terminology, it is a "singleton". This means a
* per-Application Context singleton. The factory creates a single
* instance; there is no need for a private constructor, static
* factory method etc as in the traditional implementation of
* the Singleton Design Pattern.
*
* <p>This is a POJO. It does not depend on any Spring APIs.
* It's usable outside a Spring container, and can be instantiated
* using new in a JUnit test. However, we can still apply declarative
* transaction management to it using Spring AOP.
*
* <p>This class defines a default transaction attribute for all methods.
* Note that this attribute definition is only necessary if using Commons
* Attributes auto-proxying (see the "attributes" directory under the root of
* JPetStore). No attributes are required with a TransactionFactoryProxyBean,
* as in the default applicationContext.xml in the war/WEB-INF directory.
*
* <p>The following attribute definition uses Commons Attributes attribute syntax.
* @@org.springframework.transaction.interceptor.DefaultTransactionAttribute()
*
* @author Juergen Hoeller
* @since 30.11.2003
*/
주석에 나와 있듯이 org.springframework.samples.jpetstore.service.JaxRpcOrderService 클래스를 보면 장문의 내용이 기재되어 있다.
/**
* JAX-RPC OrderService endpoint that simply delegates to the OrderService
* implementation in the root web application context. Implements the plain
* OrderService interface as service interface, just like the target bean does.
*
* <p>This proxy class is necessary because JAX-RPC/Axis requires a dedicated
* endpoint class to instantiate. If an existing service needs to be exported,
* a wrapper that extends ServletEndpointSupport for simple application context
* access is the simplest JAX-RPC compliant way.
*
* <p>This is the class registered with the server-side JAX-RPC implementation.
* In the case of Axis, this happens in "server-config.wsdd" respectively via
* deployment calls. The Web Service tool manages the lifecycle of instances
* of this class: A Spring application context can just be accessed here.
*
* <p>Note that this class does <i>not</i> implement an RMI port interface,
* despite the JAX-RPC spec requiring this for service endpoints. Axis and
* other JAX-RPC implementations are known to accept non-RMI endpoint classes
* too, so there's no need to maintain an RMI port interface in addition to
* the existing non-RMI service interface (OrderService).
*
* <p>If your JAX-RPC implementation imposes a strict requirement on a service
* endpoint class to implement an RMI port interface, then let your endpoint
* class implement both the non-RMI service interface and the RMI port interface.
* This will work as long as the methods in both interfaces just differ in the
* declared RemoteException. Of course, this unfortunately involves double
* maintenance: one interface for your business logic, one for JAX-RPC.
* Therefore, it is usually preferable to avoid this if not absolutely necessary.
*
* @author Juergen Hoeller
* @since 26.12.2003
*/
* JAX-RPC OrderService endpoint that simply delegates to the OrderService
* implementation in the root web application context. Implements the plain
* OrderService interface as service interface, just like the target bean does.
*
* <p>This proxy class is necessary because JAX-RPC/Axis requires a dedicated
* endpoint class to instantiate. If an existing service needs to be exported,
* a wrapper that extends ServletEndpointSupport for simple application context
* access is the simplest JAX-RPC compliant way.
*
* <p>This is the class registered with the server-side JAX-RPC implementation.
* In the case of Axis, this happens in "server-config.wsdd" respectively via
* deployment calls. The Web Service tool manages the lifecycle of instances
* of this class: A Spring application context can just be accessed here.
*
* <p>Note that this class does <i>not</i> implement an RMI port interface,
* despite the JAX-RPC spec requiring this for service endpoints. Axis and
* other JAX-RPC implementations are known to accept non-RMI endpoint classes
* too, so there's no need to maintain an RMI port interface in addition to
* the existing non-RMI service interface (OrderService).
*
* <p>If your JAX-RPC implementation imposes a strict requirement on a service
* endpoint class to implement an RMI port interface, then let your endpoint
* class implement both the non-RMI service interface and the RMI port interface.
* This will work as long as the methods in both interfaces just differ in the
* declared RemoteException. Of course, this unfortunately involves double
* maintenance: one interface for your business logic, one for JAX-RPC.
* Therefore, it is usually preferable to avoid this if not absolutely necessary.
*
* @author Juergen Hoeller
* @since 26.12.2003
*/
