토비의 스프링

토비의 스프링 정리 프로젝트 자바 애플리케이션 개발을 도와주는 프레임워크이다.애플리케이션의 틀, 공통 프로그래밍 모델, 기술 API 등을 제공한다.스프링 컨테이너 혹은 애플리케이션 컨텍스트로 불리는 스프링 런타임 엔진이다.설정 정보(configuration)를 참고하여

DAO(Data Access Object)는 DB를 사용해 데이터를 조회하거나 조작하는 기능을 전담하도록 만든 오브젝트를 말한다.User 클래스는 자바빈 규약을 따르는 오브젝트이다. 자바빈(JavaBean)은 원래는 비주얼 툴에서 조작 가능한 컴포넌트를 말했으나, 현재

관심사의 분리 변화에 어떻게 대응할 것인가? 핵심은 변화에 어떻게 대응할 것인가이다. 객체지향설계와 프로그래밍은 절차적 프로그래밍 패러다임에 비해 조금 더 많은 초기 비용을 소모한다. 많은 번거로운 작업들이 요구된다. 그러나, 처음에만 이러한 수고를 하여 제대로 객

DAO를 확장하기 전 현재까지의 상황 현재의 상황은 두가지 관심사를 분리한 상태이다. DB에 연결하는 Connection 부분을 다른 관심사로 분리 DAO의 행위를 다른 관심사로 분리 이 두개의 관심사가 분리된 이유는 변화의 성격이 다르기 때문이다. 변화의 성격이

IoC라는 약자로 많이 사용되는 제어의 역전(Inversion Of Control)이라는 용어가 있다. 스프링을 통해 많이 알려진 용어지만, 사실 제어의 역전이라는 개념은 상당히 오래 존재했다. IoC가 무엇인지 살펴보기 위해 UserDao 코드를 좀 더 개선해보자.원

스프링의 핵심을 담당하는 것은 빈 팩토리 혹은 애플리케이션 컨텍스트라고 불리는 것이다. 이 두 가지는 이전에 만들어본 DaoFactory를 조금 더 일반화한 것이라고 설명할 수 있다.스프링에서는 스프링이 제어권을 가지고 직접 만들고 관계를 부여하는 오브젝트를 빈(bea

동등성(equivalent)과 동일성(identical)동등성은 .equals() 메소드의 결과가 true인 경우 동등하다고 말한다.동일성은 동일한 객체(같은 주소를 가진 레퍼런스)인 경우 동일하다고 말한다.동일한 경우 동등하지만, 동등한 경우는 동일하지 않을 수도 있

객체지향적인 설계, 디자인 패턴, 컨테이너에서 동작하는 서버 기술을 사용하면 자연스럽게 IoC를 적용하거나 그 원리로 동작하는 기술을 사용하게 된다.IoC라는 단어가 매우 느슨하게 정의되어 폭넓게 사용되는 용어이기 때문에 스프링을 IoC 컨테이너라고만 해서는 스프링이

오브젝트 사이의 의존 정보는 틀에 박힌 구조를 갖고 있으며, 일일이 자바 코드로 만들어주기 번거롭다. 또, DI 구성이 바뀔 때마다 자바 코드를 수정하고 클래스를 다시 컴파일하기도 귀찮다.사실 현재에 와서는 스프링 부트 이후 레거시 프로젝트 외에는 XML로 의존관계 설

초난감 DAO에서 책임이 다른 코드를 분리하여 두 개의 클래스로 만들었다. (관심사의 분리, 리팩토링)DB 커넥션과 SQL 작업추후에 변경이 일어날 수 있는 부분은 인터페이스를 만들어 구현하도록 하고, 다른 클래스에서 인터페이스를 통해서만 접근하도록 만들었다. 인터페이

스프링이 개발자에게 제공하는 가장 중요한 가치는 객체지향과 테스트이다. 현대의 앱은 계속 변하고 복잡해져간다. 스프링의 핵심인 IoC와 DI는 오브젝트의 설계, 생성, 관계, 사용에 관한 기술이다. 객체지향 프로그래밍 언어의 근본과 가치를 개발자가 손쉽게 적용하고 사용

이전에 언급한 UserDaoTest의 두가지 문제점을 개선해보자.수동 확인 작업의 번거로움 결과를 눈으로 확인해야 했다.실행 작업의 번거로움 모든 클래스를 돌아다니며 main()을 실행해야 했다.add()에 전달한 User 오브젝트와 get()을 통해 가져온 User

스프링은 테스트를 매우 중요하게 생각한다. 테스팅 없이는 스프링도 의미 없다. 심지어 스프링 프레임워크를 만드는 과정에서도 JUnit 테스트를 이용한 테스트를 꾸준히 해왔다.스프링의 핵심 기능 중 하나인 스프링 테스트 모듈도 JUnit을 이용한다. 따라서 스프링의 기능

이전 2.3에서 위와 같이 UserDaoTest를 구성했다. 코드는 매우 깔끔하지만, JUnit의 특성상 매번 새 오브젝트를 만들게 되는데, ApplicationContext도 메소드 개수만큼 만들어진다는 것이 문제이다.현재 사용하는 수준의 ApplicationCont

때로는 자신이 만들지 않은 프레임워크나 다른 개발팀에서 만들어서 제공한 라이브러리 등에 대해서도 테스트를 작성해야 한다. 이런 테스트를 학습 테스트(learning test)라고 한다.학습 테스트의 목적은 잣니이 사용할 API나 프레임워크의 기능을 테스트로 보면서 사용

테스트는 자동화되고 빠르게 실행할 수 있어야 한다.main()을 이용하지 말고, JUnit 프레임워크를 이용하면 테스트 자동화가 가능하다.테스트 결과는 일관성이 있어야한다.환경이나 테스트 순서에 영향을 받으면 안 된다.테스트는 포괄적으로 작성해야 한다. 충분한 검증이

1장에서는 초난감 DAO 코드에 DI를 적용하여, 코드를 분리하고 확장과 변경에 용이하게 대응할 수 있는 설계 구조로 개선하는 작업을 했다. UserDao 생성,UserDao에서 Connection을 만드는 부분과 쿼리를 수행하는 부분을 다른 관심사로 분리Connect

복잡한 try/catch/finally 블록이 2중으로 중첩돼서 나오며, 모든 메소드마다 반복된다. 보통 이렇게 반복되는 코드에 대한 나쁜 습관은 따로 분리하지 않고 복사 붙여넣기로 처리하는 것이다.그러다가 어느 순간 한 줄을 빼먹고 복사하거나 몇 줄을 잘못 삭제하면

자주 변하는 부분변하지 않는 부분두 부분을 전략 패턴을 이용해 분리해냈다. 독립된 JDBC 작업 흐름이 담긴 jdbcContextWithStatementStrategy()는 DAO 메소드들이 공유할 수 있는 메소드다. 해당 메소드에 바뀌는 전략들에 대한 클래스를 추가하

이전의 방식을 전략패턴 구조로 보자면, 다음과 같다.UserDao.deleteAll(), UserDao.add(): 클라이언트어떤 전략을 사용할지 의존성을 결정익명 내부 클래스: 전략구체적인 전략UserDao.jdbcContextWithStatementStrategy(

템플릿과 콜백 전략 패턴의 기본 구조에 익명 내부 클래스를 활용한 방식은 복잡하지만 바뀌지 않는 일정한 패턴을 갖는 작업 흐름이 존재하고, 그 중 일부만 자주 바꿔서 사용하는 경우에 적합한 구조다. 스프링에서는 이러한 방식을 템플릿/콜백 패턴이라고 부른다. 전략

스프링의 JdbcTemplate 이번엔 스프링이 제공하는 템플릿/콜백 기술을 살펴보자. 거의 모든 종류의 JDBC 코드에 사용 가능한 템플릿/콜백을 제공할 뿐만 아니라, 자주 사용되는 패턴을 가진 콜백은 다시 템플릿에 결합시켜서 간단한 메소드 호출만으로 사용가능하도록

JDBC나 파일처리와 같이 예외가 발생할 가능성이 있으며, 공유 리소스의 반환이 필요한 코드는 반드시 try/catch/finally 블록으로 관리해야 한다.일정한 작업 흐름이 반복되며 그 중 일부 기능만 바뀌는 코드가 존재한다면 전략 패턴을 적용한다. 바뀌지 않는 부

예외처리의 중요성 일반적으로 개발자들은 예외처리를 하기 귀찮아한다. 정상적인 결과와 흐름을 보여주는 코드도 만들기 힘든데, 굳이 무언가 실수하거나 잘못된 시도를 해야만 볼 수 있는 예외에 신경쓰기 귀찮아한다. 그래서 예외와 관련된 코드는 자주 엉망이 되거나 무성의해지

예외 전환은 말 그대로 예외를 다른 예외로 바꿔서 던져주는 것이다. 이렇게 다른 예외로 바꾸는 목적은 두가지가 있다.체크 예외를 런타임 예외로 포장하여 불필요한 catch/throws를 줄여주는 것로우레벨의 예외를 좀 더 의미있고 추상화된 예외로 바꿔서 던져주는 것스프

바람직한 예외처리 방법을 살펴보았다. 예외 전환, 예외 감싸기가 핵심이다. JDBC 예외의 단점은 대부분의 예외가 복구 불가능함에도 불구하고 SQLException이라는 뭉뚱그린 체크 예외를 뿌려준다는 것이었는데, 스프링은 데이터 액세스 기술에서 SQLException

서비스 추상화 자바에는 표준 스펙, 상용 제품, 오픈 소스를 통틀어서 사용 방법과 형식은 다르지만 기능과 목적이 유사한 기술이 존재한다. 환경과 상황에 따라 기술이 바뀌고, 그에 따른 API를 사용하고 다른 스타일의 접근 방법을 따라야 한다는 것은 매우 피곤한 일이다

트랜잭션 서비스 추상화 사용자 레벨 작업의 특징은 사용자 데이터를 '1개씩' 조회 후에 조건에 맞는 사용자를 '1개씩' 업데이트하는 것이다. 여기서 중요한 건 '1개씩' 이라는 키워드인데 그렇다면 1000개의 데이터 중 애매하게 237개의 데이터까지 업데이트 되다가

이제 아래의 설정만 고쳐도 DB 연결 기술, 데이터 액세스 기술, 트랜잭션 기술을 자유롭게 바꿔서 사용할 수 있게 되었다. 어떻게 이런 것들이 가능했는지 되돌아보자.UserDao와 UserService는 각각 담당하는 코드의 기능적인 관심에 따라 분리되었다. 사실 둘은