토비의 스프링 정리 썸네일형 리스트형 토비의 스프링 - 6.1 트랜젝션 코드의 분리 6.1.1 AOP(Aspect Oriented Programming) AOP는 IoC/DI, 서비스 추상화와 더불어 스프링의 3대 기반기술임 AOP는 스프링의 기술 중에서 가장 난해한 용어와 개념을 가진 기술임 AOP는 주로 선언적 트랜잭션 기능에 많이 사용됨 서비스 추상화를 통해 근본적 문제를 해결 했지만, AOP로 더욱 세련되고 깔끔한 방식으로 바꿀 수 있음 AOP 등장 배경, 스프링이 AOP를 도입한 이유, AOP 적용의 장점 등을 공부할 것임 6.1.2 메소드 분리 서비스 추상화 기법을 통해 트랜잭션의 근본적 문제를 해결했지만 UserService에는 트랜잭션 로직과 비즈니스 로직이 같이 존재함 스프링이 제공하는 트랜잭션 인터페이스 PlatformTransactionManager를 사용했지만, 메.. 더보기 토비의 스프링 - 5.5 5장 정리 5.5.1 정리 비즈니스 로직과 데이터 액세스 로직은 분리되어야 함. 또한, 비즈니스 로직 내부에서도 책임과 역할에 따라 메소드로 분리되야 함 인터페이스와 DI를 이용하여 결합도를 낮춰야 함 DAO를 사용하는 비즈니스 로직에는 트랜잭션이 필요함 트랜잭션의 시작과 종료를 지정하는 일을 트랜잭션 경계설정이라 함. 주로 경계설정은 비즈니스 로직에서 많이 발생됨 트랜잭션 정보를 담은 DAO에 전달하는 방법은 매우 비효율적이기 때문에, 스프링이 제공하는 트랜잭션 동기화 방법을 사용하는 것이 편리함 자바에서 사용되는 트랜잭션 API의 종류와 방법은 많음. 트랜잭션 방법이 변경되면 경계설정 코드도 변경돼야 함 트랜잭션 경계설정 코드가 비즈니스 로직 코드에 영향을 주지 않기 위해 스프링이 제공하는 트랜잭션 서비스 추상.. 더보기 토비의 스프링 - 5.4 메일 서비스 추상화 5.4.1 JavaMail을 이용한 메일 발송 기능 새로운 요구사항 등장 레벨 업그레이드된 유저에게 안내 메일을 보내는 기능 추가 DB에 email 필드 추가 UserDao의 userMapper, insert(), update()에 emial 필드 처리 추가 테스트 데이터를 맞게 준비 및 등록, 수정, 조회에서 테스트 코드 수정 💡 앞으로 할 부분에 email 부분을 굳이 필요로 하지 않기 때문에 추가 안할것임 5.4.2 JavaMail 발송 JavaMail을 이용해 메일을 발송하는 전형적인 코드 단순한 예제이므로 한글 인코딩 부분 생략 SMTP 프로토콜을 지원하는 메일 전송 서버가 준비 되었다면 정상적으로 실행될 것임 public class UserService { ... protected void u.. 더보기 토비의 스프링 - 5.3 서비스 추상화와 단일 책임 원칙 5.3.1 수직, 수평 계층구조와 의존관계 추상화 기법을 이용하면 특정 기술환경에 종속되지 않는 포터블한 코드를 만들 수 있음 UserDao는 데이터 액세스 로직임 UserService는 사용자 관리 업무의 비즈니스 로직임 UserDao와 UserService 분리는 같은 애플리케이션 계층에서의 수평적 분리임 UserDao와 UserService는 인터페이스와 DI를 통해 연결됨으로써 낮은 결합도를 지님 즉, 독립적으로 확장 가능 마찬가지로 UserService와 트랜잭션 기술은 PlatformTransactionManager 인터페이스를 사용했기 때문에 독립적인 코드임 단, UserService와 PlatformTransactionManager는 로우 계층의 수직적 분리임 하지만, DI를 통한 수평적,.. 더보기 토비의 스프링 - 5.2 트랜잭션 서비스 추상화 5.2.1 모 아니면 도 레벨 업그레이드 도중 문제가 발생하면 이전에 업그레이드 된 것은 초기화 되는가? 일부 사용자가 차별성을 느끼기 때문에 업그레이드 도중 실패 시, 초기화 하는게 옳음 짧은 업그레이드 시간 중간에 DB 서버를 다운시키거나 네트워크에 장애 발생하는 것은 불가능 하며, 테스트는 자동화되야 하므로 예외가 발생하는 상황을 의도적으로 만들 것임 예외를 강제로 발생시킬 때 애플리케이션 코드를 수정하는 것은 좋지 않음 기존의 UserService 내부에 UserService를 상속한 테스트용 확장 static 클래스를 만들어 사용 현재 두 번째와 네 번째 사용자가 레벨 업그레이드 되므로, 네 번째 사용자 처리하는 중에 예외 발생할 것임 upgradeLevel() 메소드 오버라이드를 통해 네 번째.. 더보기 토비의 스프링 - 5.1 서비스 추상화 5.1.1 사용자 레벨 관리 기능 추가 UserDao는 CRUD를 제외하고 어떤 비즈니스 로직을 갖지 않음 사용자 관리 모듈 기능 추가 정기적으로 유저의 활용 내용을 참조해서 레벨을 조정 비즈니스 로직 사용자의 레벨은 BASIC, SILVER, GOLD 세 가지 중 하나 처음 가입자면 BASIC. 활동에 따라 한 단계씩 업그레이드 가입후 50회 이상 로그인 하면 BASIC → SILVER SILVER 이면서 30번 이상 추천을 받으면 GOLD 레벨 변경 작업은 일정 주기를 가지고 일괄적으로 진행 5.1.2 정수형 상수 값의 사용자 레벨 각 레벨을 코드화 해서 숫자로 넣음 public class User { ... int level; private static final int BASIC = 1; priv.. 더보기 토비의 스프링 - 4.3 4장 정리 4.3.1 정리 예외를 잡아서 아무런 조취를 취하지 않거나, 의미 없는 throws 선언을 남발하는 것은 위험함 예외는 복구, 전달, 전환해야 함 의미 있는 예외로 변경하거나, 불필요한 catch/throws를 피할 두 가지 방법의 예외 전환(중첩 예외, 예외 포장)이 있음 복구할 수 없는 예외는 런타임 예외로 전환하는 것이 바람직함 애플리케이션 로직을 담기 위한 예외는 체크 예외로 만듦 JDBC의 SQLEception은 복구할 수 없는 예외이므로 런타임 예외로 포장 SQLException의 에러 코드는 DB에 종속되기 때문에 DB 에 독립적인 예외로 전환될 필요성이 있음 스프링은 DataAccessException을 통해 DB에 독립적으로 적용 가능한 추상화 런타임 예외 계층을 제공 DAO를 데이터 액.. 더보기 토비의 스프링 - 4.2 예외 전환 4.2.1 JDBC의 한계 JDBC 표준 인터페이스를 통해 DB 종류에 상관없이 일관된 방법으로 프로그램을 개발할 수 있음 하지만, DB 종류에 상관없이 사용할 수 있는 데이터 엑세스 코드를 작성하는 일은 쉽지 않음 또한, 유연한 코드를 보장하지 못함 두 가지 걸림돌이 존재 비표준 SQL 호환성 없는 SQLException의 DB 에러 정보 4.2.2 비표준 SQL SQL은 어느정도 표준화된 언어이고, 몇가지 표준이 존재 하지만, 비표준 문법은 최적화된 SQL 및 DB의 특별한 기능을 제공하기 위해 사용됨 DB는 자주 변경되지 않으므로 대부분의 DB는 비표준 SQL을 지원하고 있음 해결책 호환 가능한 표준 SQL만 사용 표준 SQL만 사용하면 페이징 쿼리에서 부터 문제가 됨. 현실성 없음 DB별 별도의 .. 더보기 이전 1 2 3 4 5 6 7 다음
