체크박스 클릭 후 로그인 시 : on, 체크박스 클릭하지 않고 로그인 시 : null ( required = false 처리를 해줘야 함 ) 처리 후 체크된 상태로 로그인 성공 시 cookie 값을 발급하고 유저의 id 정보를 쿠키 값으로 저장시킨다
alter table membership add
session_id varchar2(100) default 'nan' not null;
테이블 추가
( 값이 존재하지 않는다면 nan 으로 저장된다 )
테이블 추가 완료
DB 에 추가된 컬럼을 관리할 sessionId 변수와 getter / setter 를 DTO 에 추가 >> 이후 Mapper.xml 에도 session_id 컬럼과 sessionId 변수를 mapping 시켜준다
사용자의 쿠키 값과 DB 에 저장된 값이 일치해야 자동 로그인을 처리할 것임
Service 인터페이스에 메소드 추가 >> ServiceImpl 에서는 id 값과 autoLogin 값을 HashMap 에 키와 값으로 저장하여 mapper 에 전달
Mapper 인터페이스에 메소드 추상화, Mapper.xml 에 해당 메소드에 매핑될 sql 문 작성
자동 로그인 체크 후 로그인 성공 시 DB 에 저장되는 것 확인
AutoLogin Interceptor 에서 loginCookie 값이 있는지 확인 후 해당 값이 있으면 DB 안에 설정되어 있는 session_id 의 값이 "on" 인지 체크한 뒤 session 의 LOGIN 키의 값을 id 로 생성해준다 >> servlet-context.xml 에 index 경로로 들어오기 전 실행될 AutoLogin 클래스 Interceptor 선언
servlet-context.xml 파일에서 모든 경로에서 autoLogin 으로 설정한 Interceptor 가 작동하게 설정
Controller 에서 logout 경로로 들어올 시 cookie 값을 만료시키고 DB 안에 on 으로 저장되어 있던 session_id 컬럼의 값을 nan 으로 변경시킨뒤 세션을 모두 삭제하고 login 페이지로 돌려보낸다
Interceptor : 컨트롤러로 가기 전에 무언가 처리할 내용 ( preHandle ) 이나, 컨트롤러 까지 로직 작동 후 클라이언트에게 도착하기 전에 처리할 내용 ( postHandle ) 을 담당 ( 불필요한 리소스를 차단 )
Interceptor 패키지, 클래스 파일 생성
메소드 오버라이딩
servlet-context.xml 파일에 MemberInterceptor 클래스를 /index 경로가 실행될때 사용할 Interceptor 로 설정 ( /index 경로로 접속할때 컨트롤러로 전달되기 전 오버라이딩 한 메소드인 preHandle 이 실행, 컨트롤러로 전달된 후 오버라이딩 한 메소드인 postHandle 이 실행된다 )
MemberInfo 를 로그인한 사용자만 확인할 수 있게 Interceptor 를 사용해서 설정할 것임 >> Controller 에서도 세션을 기준으로 redirect 로 처리할 수 있음 그러나 로직을 세션을 비교하는 부분마다 다 작성해줘야 하기 때문에 비효율적....
servlet-context.xml 에 Interceptor 로 미리 로직을 분류할 경로를 추가 >> session 값을 미리 Controller 에 도착하기 전에 Interceptor 에서 확인하여 Controller 로 이동시킬지 Controller 로 이동시키지 않고 redirect 로 login 페이지로 이동시킨다
사용 이유 : 싱글톤 패턴은 전체 애플리케이션에서 단 하나의 인스턴스만을 생성하여 사용하고자 할 때 사용한다
이는 공유 리소스 관리나 크로스-커팅 서비스( 애플리케이션의 여러 부분에 걸쳐 공통적으로 적용되는 기능을 말한다 ) 제공에 유용하다
스프링에서는 기본적으로 모든 빈객체를 싱글톤으로 생성하여 관리한다
싱글톤 사용의 장점
1. 메모리 낭비 방지
2. 전역 인스턴스로 애플리케이션 어디서나 접근이 가능
3. 데이터 공유의 용이성
싱글톤 사용의 단점
1. 싱글톤 인스턴스가 너무 많은 역할을 담당하게 되면 변경과 테스트가 어려워진다
2. 멀티스레드 환경에서 동기화 처리가 필요하다 ( 생성된 빈 객체를 동시에 사용할 수 없기 때문 )
팩토리 메소드 패턴 ( Factory Method Pattern )
사용 이유 : 객체 생성 처리를 서브 클래스로 분리하여 객체 생성 로직의 변경이나 확장이 필요할 때 유연하게 대처하기 위해 사용
스프링에서 인스턴스 생성을 추상화하고, 이를 상속받는 서브 클래스에서 해당 인스턴스의 구체적인 타입을 결정하게 하게 한다
public interface PaymentProcessor {
void processPayment();
}
public class CreditCardProcessor implements PaymentProcessor {
@Override
public void processPayment() {
// 신용카드 결제 로직 처리
}
}
public class PayPalProcessor implements PaymentProcessor {
@Override
public void processPayment() {
// PayPal 결제 로직 처리
}
}
@Component
public class PaymentProcessorFactoryImpl implements PaymentProcessorFactory {
@Override
public PaymentProcessor createPaymentProcessor() {
// 설정 등에 따라 생성할 프로세서 결정 로직
return new CreditCardProcessor();
}
}
코드 예시로서 결제에 관련된 인터페이스를 생성한 뒤 해당 인터페이스를 상속받아 기능에 따라 다양하게 구현
팩토리 메소드 패턴 사용의 장점
1. 유연성 : 팩토리 메소드 패턴은 프로그램 실행 중에 어떤 객체를 생성할지 결정할 수 있게 해준다, 이는 프로그램이 더 유연하게 동작하도록 돕는다
2. 낮은 결합도 : 클라이언트 코드가 구체적인 클래스를 몰라도 되기 때문에 서로 간의 의존성이 낮아진다
3. 유지보수의 용이성 : 팩토리 메소드 패턴을 사용하면 새로운 객체 타입을 추가하거나 변경해도 기존 코드를 수정할 필요가 없어 유지보수가 쉬워진다
팩토리 메소드 패턴 사용의 단점
1. 복잡성 증가 : 팩토리 메소드 패턴을 사용하면 각 객체마다 팩토리 클래스가 필요하기 때문에 코드가 복잡해질 수 있다
2. 서브 클래스 증가 : 새로운 객체 타입을 추가할때마다 새로운 서브 클래스를 만들어야 하기 때문에 클래스의 갯수가 증가하며 프로젝트의 크기와 복잡성을 증가시킬 수 있다 ( 서브 클래스의 증가는 관리해야 할 코드의 양의 증가와 테스트와 디버깅을 더 복잡하게 만들 수 있다 )
프록시 패턴 ( Proxy Pattern )
사용 이유 : 원본 객체에 대한 접근을 제어하거나, 원본 객체의 생명주기를 관리하거나, 원본 객체의 작업을 가상화하기 위해 사용
// 파일 인터페이스
public interface File {
byte[] load();
}
// 실제 파일을 로드하는 클래스
public class RealFile implements File {
private String path;
public RealFile(String path) {
this.path = path;
loadFromDisk(path);
}
private void loadFromDisk(String path) {
System.out.println("디스크에서 파일 로드: " + path);
}
@Override
public byte[] load() {
System.out.println("파일 내용을 반환합니다.");
return new byte[0]; // 실제 파일 내용을 반환
}
}
// RealFile 객체의 생성을 지연시키는 프록시 클래스
public class ProxyFile implements File {
private RealFile realFile;
private String path;
public ProxyFile(String path) {
this.path = path;
}
@Override
public byte[] load() {
if (realFile == null) {
realFile = new RealFile(path);
}
return realFile.load();
}
}
// 클라이언트 코드
public class ProxyExample {
public static void main(String[] args) {
File file = new ProxyFile("test_file.txt");
// 파일이 실제로 필요할 때만 로드됩니다.
file.load();
}
}
예시 코드 ( ProxyFile 클래스에서는 요청한 파일의 객체가 이미 생성된 상태라면 다시 파일을 불러와서 객체를 생성하는 과정을 거치지 않고 이미 생성되어 있는 객체를 재사용한다 )
Member 클래스 생성 ( Entity 어노테이션으로 해당 클래스를 DataBase 역할을 하는 빈 객체로 등록 후 id, name 변수 선언 및 getter / setter 선언 ), Id 어노테이션을 사용해서 id 값이 primary key 임을 선언
DB 안에 데이터 빈 것 확인 >> jpa 를 사용하여 DB 에 데이터 저장 >> 데이터 저장된 것 확인
try catch finally 를 사용하여 예외 처리 및 자원 관리를 진행
위와 같이 insert 문을 다시 실행시켜 id : 2 , name : HelloB 데이터를 입력하려고 하니 기존에 DB 에 있던 id : 1, name : HelloA 데이터가 삭제되고 새로 넣은 데이터만 나오는 것을 확인
persistence.xml 에서 hibernate 옵션 중 hbm2ddl.auto 의 값이 create 로 설정되어 있는데 이 설정은 애플리케이션을 재시작할 때마다 데이터베이스를 새로 생성하기 때문에 기존 데이터가 삭제되므로 해당 값을 update 로 변경해주거나 주석처리한다 ( 나는 주석처리 후 진행 ) >> 이후 다시 명령문 실행 후 확인
( 배포 환경에서는 이 속성 자체를 사용하지 않는 편이 좋다 )
entityManager 의 find 메소드를 사용하여 id 값이 1인 데이터를 찾아온 뒤 출력 >> 찾아온 데이터의 name 값을 HelloJPA 로 변경 >> 변경된 것 확인
@Transactional = insert, delete 와 같은 쿼리문을 테스트한 뒤 다시 롤백하여 처음 상태로 돌려주는 어노테이션
memberMapper.xml 에 select 문 작성 ( 현재 가져올 컬럼 중 primary key 가 없기 때문에 모두 result 태그를 사용, 만약 가져오는 컬럼 중 primary 키가 있는 컬럼은 result 가 아닌 id 태그로 매핑해줘야 한다 )
result : primary key 가 아닌 컬럼 mapping
id : primary key 인 컬럼 mapping
DAO 에 select 문을 실행시킬 list 메소드 작성
TestMember.java 에서 단위 테스트 진행 ( DAO 만 실행 테스트 ) >> null 이 아니면 초록색 바
MemberService 인터페이스 작성 ( jsp 쪽으로 데이터 전달해 줄 것이므로 model 객체를 전송 ) >> MemberServiceImpl 에서는 해당 model 객체를 받아서 model 객체 안에 list 라는 이름으로 DAO 의 list 메소드가 반환한 값을 addAttribute 로 추가해준다
Controller 에서 Service 의 list 메소드 호출할때 model 객체 넘기는 코드 작성
통합 테스트 진행 >> 성공
index.jsp 작성 후 테스트 >> list 객체 잘 들어오며 사이즈와 데이터 값도 잘 출력되는 것 확인
기존 insert 경로는 데이터 추가 후 바로 jsp 파일을 출력해서 list 가 존재하지 않아 출력되지 않았는데 이를 출력해주기 위해 redirect 를 사용해서 클라이언트가 다시 요청해서 데이터를 받게끔 설정 >> 이렇게 리다이렉트를 설정해주면 통합 테스트에서 리다이렉트가 정상적으로 진행되는지를 따로 설정해주지 않으면 오류가 발생되므로 코드를 변경해준다
메이븐 프로젝트 업데이트 ( 단축키 Alt + F5 ) >> JRE System Library 에 JavaSE 버전이 1.8 로 변경된 것 확인
※ 꼭 업데이트는 pom.xml 변경 후 저장한뒤 할 것 ※
HikariCP 라이브러리 추가
Spring JDBC 아무 버전이나 라이브러리 추가 >> 상단에 내가 사용중인 스프링 버전의 변수를 복사 >> 내 스프링 버전으로 변경
Oracle DB 버전 확인 후 라이브러리 추가 ( Oracle DB 버전이 11 버전 : ojdbc6 설치, Oracle DB 버전이 19 버전 이상 : ojdbc8 에 맞는 버전으로 설치 ) >> 나는 Oracle DB 버전이 19.3.0.0 버전이므로 ojdbc8 의 19.3.0.0 버전 라이브러리를 추가
MyBatis 버전 3.4.6 라이브러리 추가
MyBatis 와 Spring 을 연동시켜주는 MyBatis Spring 을 버전 1.3.2 로 설치
Controller 에 사용자가 아이디, 비밀번호 입력 시 이동될 user_check url 작성
MemberService 인터페이스에 user_check 메소드 선언 >> MemberServiceImpl 에서는 MemberMapper 를 통해 id 값에 해당하는 DB 저장 값을 가져와 DTO 에 저장하고 해당 값으로 입력된 비밀번호와 일치하면 0을 리턴, 아니면 1을 리턴한다
MemberMapper 인터페이스에 user_check 메소드를 추상화 >> MemberMapper.xml 에서 select 문을 작성 ( id : 메소드명, resultMap : 결과를 위에서 선언한 MemberDTO 형태로 매핑하여 가져오겠다는 뜻 )
session 의 값들을 처리할 인터페이스 생성 >> Controller 에서는 session 을 처리할 인터페이스인 MemberSessionName 을 상속받은 뒤 사용 >> successLogin.jsp 에서는 세션 값인 loginUser 를 출력 >> 결과