토비의 스프링 정리 썸네일형 리스트형 토비의 스프링 - 4.1 사라진 SQLException 4.1.1 JdbcContext에서 JdbcTemplate로 적용 JdbcContext를 JdbcTemplate로 바꾸니 throws SQLException이 사라짐 //JdbcContext public deleteAll() throws SQLException { this.jdbcContext.update("delete from users"); } //JdbcTemplate public deleteAll() { this.jdbcTemplate.update("delete from users"); } 4.1.2 초난감 예외처리 try/catch로 예외를 잡고 아무것도 안하는 것은 예외 발생시 무시하고 계속 진행하기 때문에, 그냥 예외가 발생 했을 때 보다도 더 나쁜 코드임 try{ ... }catch(SQL.. 더보기 토비의 스프링 - 3.7 3장 정리 3.7.1 정리 JDBC와 같은 예외가 발생할 가능성이 있으며 리소스 반환이 필요한 코드는 try/catch/finally 블록으로 관리 일정한 작업 흐름이 반복되면서 그중 일부만 바뀌는 코드가 존재한다면 전략패턴 적용. 바뀌지 않는 부분은 컨텍스트로, 바뀌는 부분은 전략으로 만들고 인터페이스를 통해 유연하게 전략을 변경할 수 있도록 구성 인터페이스를 상속한 자바 클래스가 많아진다면, 클라이언트 메소드에서 직접 전략을 정의 및 제공 익명 내부 클래스를 이용해 전략 오브젝트를 구현하면 코드가 간결해짐 컨텍스트가 하나 이상의 클라이언트 오브젝트 에서 사용되면 클래스로 분리 해서 여러 클라이언트가 사용할 수 있게 함 컨텍스트는 빈으로 등록해서 DI를 받거나, 직접 생성해서(new) 수동 DI를 하면 됨 단일 .. 더보기 토비의 스프링 - 3.6 스프링의 JdbcTemplate 3.6.1 JdbcTemplate 스프링이 제공하는 JDBC 코드용 기본 템플릿 JdbcTemplate은 생성자의 파라미터로 DataSource를 주입하면 됨 JdbcTemplate는 DAO 안에서 만들어 수동 DI를 하는 것이 관례임 하지만, 낮은 결합도를 위해 JdbcTemplate를 독립적인 빈으로 등록하고 JdbcTemplate가 구현하고 있는 JdbcOperations 인터페이스를 통해 DI받아 사용하도록 해도 됨 public class UserDao { private JdbcTemplate jdbcTemplate; private DataSource dataSource; public void setDataSource(DataSource dataSource) { this.dataSource = d.. 더보기 토비의 스프링 - 3.5 템플릿과 콜백 3.5.1 템플릿(template) 어떤 목적을 위해 미리 만들어둔 모양이 있는 틀 고정된 틀 안에 바꿀수 있는 부분을 넣어서 사용하는 경우를 템플릿이라 함 변하는 것과 변하지 않는 것을 분리 고정된 틀의 로직을 갖는 템플릿 메소드를 슈퍼 클래스에 두고, 바뀌는 부분을 서브 클래스의 메소드에 두는 구조 3.5.2 콜백(Callback) 실행되는 것을 목적으로 다른 오브젝트의 메소드에 전달되는 오브젝트 파라미터로 전달되지만, 값을 참조하는 것이 아닌 특정 로직을 담은 메소드 실행을 목적 자바에서는 메소드 자체를 전달하는 방법이 없기 때문에 메소드가 담긴 오브젝트를 전달 이를, 펑셔널 오브젝트(Functional Object)라 함 3.5.3 템플릿/콜백 템플릿은 작업 흐름을 가진 코드를 재사용한다는 의미에.. 더보기 토비의 스프링 - 3.4 컨텍스트와 DI 3.4.1 JDBCContext의 분리 전략 패턴의 구조로 봤을 때 클라이언트 : UserDao 메소드 개별적 전략 : 익명 내부 클래스로 만들어 진 것 컨텍스트 : jdbcContextWithStatementStrategy() 컨텍스트 메소드(add(), deletelAll())는 UserDao내 PrepareStratement를 실행하는 메소드(Test 클래스에서 만들어진 것들)에서 공유할 수 있음 JDBC의 일반적 흐름인 jdbcContextWithStatementStrategy()는 다른 DAO에서 사용 가능하므로 UserDao 클래스 밖으로 독립 해당 클래스 이름을 JdbcContex로 함. 메소드 이름은 workWithStatementStrategy() 클래스 분리로 인해 Datasource는.. 더보기 토비의 스프링 - 3.3 JDBC 전략 패턴의 최적화 3.3.1 전략 클래스의 추가정보 add()에는 User 정보를 받아와서 PrepareStatement를 실행해야 함 해당 User 정보는 클라이언트로 부터 생성자의 파라미터로 받으면 됨 try/catch/finnaly 컨텍스트를 공유할 수 있게 됨 코드의 양이 매우 줄어듦 하지만, 두 가지 문제점 있음 템플릿 메소드 패턴과 비슷하게 DAO 메소드 마다 새로운 StatementStrategy 구현 클래스를 만들어야 함. 클래스의 양이 너무 많아짐 StatementStrategy에 전달할 User와 같은 부가 정보가 있을 경우, 이 정보를 받기 위해 생성자 및 인스턴스 변수 필요 public class AddStatement implements StatementStrategy{ private User us.. 더보기 토비의 스프링 - 3.2 변하는 것과 변하지 않는 것 3.2.1 JDBC trt/catch/finally 코드의 문제점 코드가 너무 난잡함 close()를 제대로 하지 않으면 리소스 문제 발생 수정할 코드를 찾는 것이 어려움 예외상황을 처리하는 테스트 코드를 만들기 힘듦(인터페이스 구현체를 만들어야 하기 때문) 💡 난잡한 코드를 해결하기 위해 변하는 것과 변하지 않는 것을 분리하여 리팩토링 해야함 3.2.2 분리 변하는 것과 변하지 않는 것을 분리 deleteAll()에서 ps 만이 변하는 부분임 변하는 부분만 메소드 추출하면 추출한 메소드를 다른곳에 재사용할 수 있어야 하는데, 이와 반대로 추출된 메소드만 재사용이 필요한 부분으로 변경됨 public void deleteAll() throws SQLException { PreparedStatement ps.. 더보기 토비의 스프링 - 3.1 다시 보는 초난감 DAO 3.1.1 개방 폐쇄 원칙과 템플릿 개방 폐쇄 원칙은 확장은 열리고 변경에는 닫여야 한다는 뜻임 즉, 코드 수정을 통해 그 기능이 다양해지고 확장하려는 성질이 있고, 어떤 부분은 고정되어 있고 변하지 않으려 고정되는 성질이 있다는 뜻임 템플릿이란, 일정 패턴으로 유지되는 부분을 확장되는 부분으로부터 독립시켜 효과적으로 활용할 수 있도록 하는 방법임 3.1.2 예외처리 기능을 갖춘 DAO JDBC는 예외처리를 반드시 해야하는 원칙이 있음 예외 발생시에도 리소스 반환을 꼭 해야함 Connection과 PrepareStatement는 보통 풀(pool) 방식으로 운영됨 풀 방식은 미리 만든 리소스를 돌려가며 필요할 때 할당을 하고, 반환하면 다시 풀에 넣는 방법임 이 제한된 리소스를 고갈되지 않게 해야함 Us.. 더보기 이전 1 2 3 4 5 6 7 다음
