본문 바로가기

Back-End/토비의 스프링3

 (24)
토비의 스프링 6장(4) - 스프링의 프록시 팩토리 빈 스프링의 프록시 팩토리 빈 이전까지 자바를 이용하여 기존 코드 수정없이 부가기능을 추가해주었다. 이제 스프링에서는 어떠한 방식으로 추가해주는지 살펴보자. ProxyFactoryBean 자바 JDK에서 제공하는 다이나믹 프록시 외에도 편리하게 프록시를 만들 수 있도록 지원해주는 다양한 기능이 있다. 스프링은 프록시 오브젝트를 생성해주는 기술을 추상화한 팩토리 빈을 제공해준다. package com.waug.common.currency.service; import org.aopalliance.intercept.MethodInterceptor; import org.aopalliance.intercept.MethodInvocation; import static org.hamcrest.MatcherAssert.a..
7장. 스프링 핵심 기술의 응용 앞 장에서 스프링의 3대 핵심 기술인 IoC/DI, 서비스 추상화, AOP에 대해 살펴봤다. 스프링의 모든 기술은 결국 자바의 핵심 가치인 객체지향 적인 코드를 작성할 수 있도록 도와주는 것이다. 스프링을 사용하는 개발자라면 당연히 스프링이 제공해주는 3가지 기술을 필요에 따라 스스로 응용할 수 있어야 한다.
7.4. 인터페이스 상속을 통한 안전한 기능확장 서버가 운영중인 상태에서 사용 중인 SQL을 변경해야 한다면? 이렇게 기존의 기능에 발전돼야 할 경우 스프링에서는 어떻게 접근하는지에 대해 알아보자. DI와 기능의 확장 스프링의 DI 프레임워크를 쓴다고 해서 DI를 바르게 활용한다고 볼 수 없다. 스프링에서 DI를 쓰는건 어렵지 않은 일이다. 하지만 DI의 가치를 제대로 얻기위해 DI에 적합한 오브젝트 설계는 쉽지 않다. 그렇다면 DI의 가치를 얻기위해서는 어떻게 하는게 좋을까? 객체지향 설계를 하면서 DI를 의식하면서 설계를 하는 것도 좋은 방식이다. DI와 interface 프로그래밍 인터페이스를 통해 다형성을 얻을 수 있고, 유연하고 확장성 높은 설계가 가능해진다. 앞장에서 우리는 아래처럼 설계를 해왔다. 이제 여기에서 이미 등록된 SQL을 변경할..
7.2. 인터페이스의 분리와 자기참조 빈 & 7.3. 서비스 추상화 적용 SQL을 읽어오는 작업을 시작해보자. SqlService라는 인터페이스를 만들고 구현하면 끝일까? 이는 인터페이스를 사용하는 척만 하고 구현체에 방대한 서브시스템을 몰아넣게 될 것이다. 변화를 위한 준비 : 인터페이스 분리 1) XML에서 SQL 데이터를 가져오고 2) HashMap 맵 오브젝트에 저장을 해두는 XmlSqlService를 잘 만들었다. 하지만, 스프링의 유연한 확장구조를 경험한 개발자라면 당연히 수정을 해야한다. 만약, XML 대신 다른 포맷의 파일에서 SQL을 읽어온다면? XmlSqlService를 뜯어 고쳐야 한다. 다른 ...SqlService를 똑같이 만든다면 코드의 중복이 일어날테고, 그렇다고 XmlSqlService를 뜯어고치는 것도 잘못된 방법이다. 왜냐하면 수정되는 이유가 ..
7.6 스프링 3.1 DI & 7.7 정리 스프링 프레임워크가 나온지가 어느덧 8년이 되었다. 스프링 1.0에서 3.1까지 나오면서 완벽에 가까울 만큼 하위 호환성을 가지고 있다고 한다. 이는, 스프링에서 항상 얘기하는 DI 패턴을 스스로 잘 지켰기 때문이다. 스프링 3.1에 이르러서는 1. 핵심 로직을 담은 자바 코드 2. DI 프레임워크 3. DI를 위한 메타데이터로서의 자바 코드 ( 구버전 때 XML ) 크게 이렇게 3가지로 구성 되어 있다. 컨텍스트 분리와 @Import 이전 예제까지는 DI 정보와 테스트를 수행하기 위해 만든 DI 정보가 하나의 파일 안에 혼재해 있다. 결국, 성격이 다른 코드 분리에 실패한 것이다. 이제 DI 정보를 분리해보자. 테스트에서 사용할 빈정보를 다른 클래스로 분리했으니 완벽한 코드일까? 빈의 내용을 보면 SQ..
6.8장 - 트랜잭션 지원 테스트
6-6. 트랜잭션 속성 & 6-7. 어노테이션 트랜잭션 속성과 포인트컷 이전 포스팅에서 스프링의 트랜잭션 추상화를 설명하면서 넘어간게 하나 있다. 트랜잭션 매니저에서 트랜잭션을 가져올 때 사용한 DefaultTransactionDefinition 오브젝트다. 트랜잭션 정의 더 이상 쪼갤 수 없는 최소 단위의 작업이라는 점에서 모두 같은 개념이지만, 트랜잭션의 동작방식을 제어할 수 있는 다른 몇가지 조건이 있다. 트랜잭션 전파 ( Transaction Propagation ) 트랜잭션의 경계에서 이미 진행 중인 트랜잭션이 있을 때 또는 없을 때 어떻게 동작할지 결정하는 방식 예제 : A 트랜잭션이 끝나지 않은 시점에서 B를 호출했다면 B는 어떤 트랜잭션 안에서 동작할까? A+B 하나의 트랜잭션으로 처리 : (2)에서 에러가 나면 B도 롤백이 된다. A / B 별도의 트랜잭션으..
9.3. 스프링 웹 애플리케이션 아키텍처에 관하여 들어가기 전 스프링 프로젝트를 하면, 일단 기본적으로 생각없이 Controller, Service, Repository 3단계로 나누어 코딩을 한다. 어떤 역할로 나눈지는 이해하고 있었지만, 어떻게 서로 결합도를 낮추고, 어떠한 방식으로 아키텍처를 정하는지에 대한 이해도는 거의 없었다. 그래서 토비의 스프링에 있는 9.3. 애플리케이션 아키텍처를 읽게 되었다. 계층형 아키텍처 우리는 스프링을 공부하면서 관심, 책임, 성격, 변하는 이유와 방식이 서로 다른것들을 분리함으로써 결합도는 낮추고 응집도는 높이는 코드를 만들어 왔다. 웹 애플리케이션에서도 이처럼 성격이 다른 것은 아키텍처 레벨에서 분리해주는 것이 좋다. 만약, 분리하지 않고 JSP 처럼 HTML, JDBC 코드가 함께 존재한다면? 유지보수는 거의..
토비의 스프링 7장(1) - SQL과 DAO의 분리 4,5,6장을 살펴보면서 스프링의 3대 핵심 기술인 IoC/DI, 서비스 추상화, AOP에 대해 간단히 살펴봤다. 스프링이 자신의 핵심 기술을 다양한 분야에 적용했듯이, 스프링을 사용하는 개발자도 스프링이 제공하는 3가지 기술을 필요에 따라 스스로 응용할 수 있어야 한다. SQL과 DAO의 분리UerDao에서 반복적인 JDBC 작업 흐름을 템플릿을 이용해 제거했다. 그리고 다른 부분과의 연결을 인터페이스를 통해 DI 되기 때문에 다이나믹하게 관계를 설정할 수 있다. 즉, DAO에는 깔끔하게 다듬어진 순수한 데이터 액세스 코드만 남게 했다. 하지만, DB테이블과 필드정보를 고스란히 담고 있는 SQL 문장이 남아있다. DB의 테이블, 필드 이름과 SQL 문장의 변경으로 UserDAO를 수정하게 될 수도 있다..
토비의 스프링 6장(3) - 다이나믹 프록시와 팩토리 빈 프록시 패턴 / 데코레이터 패턴6-1장에서 트랜잭션 코드와 비즈니스 코드를 분리했었다.( http://happyer16.tistory.com/entry/%ED%86%A0%EB%B9%84%EC%9D%98-%EC%8A%A4%ED%94%84%EB%A7%81-6%EC%9E%A51-AOP-%ED%8A%B8%EB%9E%9C%EC%9E%AD%EC%85%98-%EC%BD%94%EB%93%9C%EC%9D%98-%EB%B6%84%EB%A6%AC ) 위의 구조를 다시 그린 후에 프록시에 대한 개념을 살펴보면 이해하기 편하다. 프록시와 타킷아래 그림은 위의 구조와 같은 것이다. 프록시(Proxy) : 클라이언트가 사용하려고 하는 실제 대상인 것처럼 위장해서 클라이언트의 요청을 받아주는 대리자 ( UserServiceTx )타..

티스토리툴바