[7주차](이세원, 김동하, 박준영) #8
Comments
📚6.7 ~ 6.9장 정리트랜잭션 애노테이션
@transactional
@Transactional(readOnly=true)@Target({ElementType.TYPE, ElementType.METHOD})
@Retention(RetentionPolicy.RUNTIME)
@Inherited
@Documented
public @interface Transactional {
@AliasFor("transactionManager")
String value() default "";
@AliasFor("value")
String transactionManager() default "";
String[] label() default {};
Propagation propagation() default Propagation.REQUIRED;
Isolation isolation() default Isolation.DEFAULT;
int timeout() default TransactionDefinition.TIMEOUT_DEFAULT;
String timeoutString() default "";
boolean readOnly() default false;
Class<? extends Throwable>[] rollbackFor() default {};
String[] rollbackForClassName() default {};
Class<? extends Throwable>[] noRollbackFor() default {};
String[] noRollbackForClassName() default {};
}트랜잭션 속성을 이용하는 포인트컷
대체 정책
[1]
public interface Service {
[2]
void method1();
[3]
void method2();
}
[4]
public class Servicelmpl implements Service {
[5]
public void method1() (
[6]
public void method2() {
}
트랜잭션 애노테이션 적용
@Transactional
public interface UserService {
void upgradeLevels();
void add(User user);
@Transactional(readOnly = true) // default : false
User get(String id);
@Transactional(readOnly = true)
List<User> getAll();
void deleteAll();
void update(User user);
}장점
단점과 주의사항
@transactional 테스트테스트를 위한 트랜잭션 애노테이션@transactional
@Rollback
public class UserServiceTest {
...
@Test
@Transactional
@Rollback(false)
public void transactionSync() {
...
}
}@TransactionConfiguration
@RunWith(SpringJUnit4ClassRunner.class)
@ContextConfiguration(locations = "/applicationContext.xml")
@Transactional
@TransactionConfiguration(defaultRollback = false) //롤백되지 않음
public class UserServiceTest {
@Test
@Rollback //롤백됨
public void add(){}
}@NotTransactional과 Propagation.NEVER
@Transactional(propagation = Propagation.NEVER)정리
|
📚토비의 스프링 7장 스프링 핵심 기술의 응용1️⃣ SQL과 DAO의 분리이전 챕터들에서 반복적인 JDBC 작업 흐름은 템플릿을 이용해 DAO에서 완벽하게 제거했다. DAO 인터페이스, JDBC라는 처리 기술, 정보를 담는 오브젝트가 바뀌지 않는다면 DAO 코드가 수정될 일은 없다. 따라서 SQL을 적절히 분리해 DAO 코드와 다른 파일이나 위치에 두고 관리할 수 있다면 좋을 것이다. 2️⃣ XML 설정을 이용한 분리SQL을 스프링의 XML 설정 파일로 분리하는 것이다. 스프링은 설정을 이용해 값을 주입할 수 있다. SQL은 문자열로
public class UserDaoJdbc implements UserDao{
private String sqlAdd;
...
}
-----
public void add(User user){
this.jdbcTemplate.update(
this.sqlAdd,
user.getId(), user.getPassword(), ...
);
}
-----
<bean id="userDao" class="~~~~~~">
<property name="sqlAdd" value="insert into users(id, name, password)
values (?,?,?)/>
</bean>sqlAdd를 사용하는 SQL은 코드의 수정 없이 XML 설정을 바꿔서 자유롭게 수정이 가능하다.
public class UserDaoJdbc implements UserDao{
private Map<String, String> sqlMap;
...
}
-----
public void add(User user){
this.jdbcTemplate.update(
this.sqlMap.get("add"),
user.getId(), user.getPassword(), ...
);
}
-----
<bean id="userDao" class="~~~~~~">
<property name="sqlMap>
<map>
<entity key="add" value="insert into users(id, name, password)
values (?,?,?) />
<entity key="get" value="select * from users where id =?"/>
</map>
</bean>이렇게 맵으로 만들어두면 새로운 SQL이 필요할 때 3️⃣ SQL 제공 서비스설정파일 안에 SQL을 두고 이를 DI해서 DAO가 사용하게 하면 SQL을 분리할 수 있지만 몇 가지 문제점이 존재한다.
이러한 문제점을 해결하려면 DAO가 사용할 SQL을 제공해주는 기능을 독립시킬 필요가 있다. 즉, 독립적인 SQL 제공 서비스가 필요하다. public interface SqlService{
Strinig getSql(String key) throws someException;
}
------
public class SimpleSqlService implements SqlService{
private Map<String, String> sqlMap;
public String getSql(String key) throws someException{
String sql = sqlMap.get(key);
...
}
}SQL 서비스는 SQL에 대한 키 값을 전달하면 그에 해당하는 SQL을 전달하는 기능을 한다. public class UserDaoJdbc implements UserDao{
private SqlService sqlService;
...
}
-----
public void add(User user){
this.jdbcTemplate.update(
this.sqlService.getSql("userAdd"),
user.getId(), user.getPassword(), ...
);
}
-----
<bean id="userDao" class="~~~~~~">
<property name="sqlService" ref="sqlService"/>
</bean>
<bean id="sqlService" class="~~~~~">
<property name="sqlMap">
<map>
<entity key="userAdd" value="insert into users(id, name, password)
values (?,?,?) />
<entity key="userGet" value="select * from users where id =?"/>
</map>
</property>
</bean>코드와 설정만 놓고 보면 앞에서 사용했던 방법과 별로 다른 것이 없어 보인다. 4️⃣ 인터페이스 분리와 자기참조 빈XML 파일 매핑스프링 XML 설정 파일에서 JAXB(Java Architecture for XML Binding)JAXB는 XML에 담긴 정보를 파일에서 읽는 방법 중 하나이다. XML 정보를 오브젝트처럼 다룰 수 있어 편리하다는 장점이 있다.
XML SQL 서비스public class XmlSqlService implements SqlService {
private Map<String, String> sqlMap = new HashMap<String, String>(); // 읽어온 SQL을 저장해둘 맵
public XmlSqlService() {
String contextPath = Sqlmap.class.getPackage().getName();
try {
JAXBContext context = JAXBContext.newInstance(contextPath);
Unmarshaller unmarshaller = context.createUnmarshaller();
InputStream is = UserDao.class.getResourceAsStream("sqlmap.xml");
Sqlmap sqlmap = (Sqlmap) unmarshaller.unmarshal(is);
for (SqlType sql : sqlmap.getSql()) {
sqlMap.put(sql.getKey(), sql.getValue());
}
} catch (JAXBException e) {
throw new RuntimeException(e);
}
}
}위 코드의 문제점
코드의 로직과 다른 이유로 바뀔 가능성이 있는 내용은 외부에서 DI로 설정해줄 수 있게 하자. 여기서 이렇게해도 SQL을 가져오는 방법이 특정 기술에 고정되어 있다. 다른 포맷의 파일을 읽어와야하면 XmlSqlService를 직접 수정해야한다. 여기서 분리 가능한 관심사가 생긴다.
SqlReader는 읽어온 다음에 SqlRegistry에 전달해서 등록되게 해야한다. 자기참조 빈으로 구현하자책임에 따라 분리되지 않았던 XmlSqlService 클래스를 세분화된 책임을 정의한 인터페이스(SqlReader, SqlSeivice, SqlRegistry)를 구현하자. SqlService 메서드에서
를 통해 간접적으로 접근하게 했다. 이제 빈 설정을 통해 실제 DI가 일어나도록 해야 한다. <bean id="sqlService" class="~~~~~">
<property name="sqlReader" ref="sqlService" />
<property name="sqlRegistry" ref="sqlService" />
</bean>자기 참조빈은 사실 흔히 쓰이는 방법이 아니다. 확장이 힘들고 변경에 취약한 구조의 클래스를 유연한 구조로 만들려고 할 때 처음 시도해볼 수 있는 방법이다. 5️⃣ 서비스 추상화 적용OXM 서비스 추상화XML과 자바 오브젝트를 매핑해서 상호 변환해주는 기술을 간단히 OXM(Object-XML Mapping)이라고도 한다. JAXB 외에 로우 레벨의 구체적 기술과 API에 종속되지 않고 추상화된 레이어와 API를 제공해서 구현 기술에 대해 독립적인 코드를 작성할 수 있다. public interface Unmarshaller {
Object unmarshal(Source source) throws IOException, XmlMappingException;
}이제 추상화된 OXM 기능을 이용하는 SqlService를 구현하자. public class OxmSqlService implements SqlService {
private final OxmSqlReader oxmSqlReader = new OxmSqlReader();
private class OxmSqlReader implements SqlReader {
...
}
}SqlRegistry는 DI받고 SqlReader는 사용성 극대화를 위해 스프링의 OXM 언마샬러를 이용하도록 고정한다. 6️⃣ 인터페이스 상속을 통한 안전한 기능 확장원칙적으로 권장되진 않지만 때로는 서버가 운영 중인 상태에서 서버를 재시작하지 않고 긴급하게 애플리케이션이 사용 중인 SQL을 변경해야 할 수도 있다. DI와 기능의 확장인터페이스를 사용해야 하는 이유
인터페이스를 사용한 DI의 관한 내용은 앞에서 다룬 내용이기에 따로 정리하지 않았습니다. 인터페이스와 DI를 통한 유연한 확장구조.jpg 인터페이스 상속을 이용한 확장구조.jpg |
The text was updated successfully, but these errors were encountered: